|
That really does sound promising, doesn't it? :) You control the mapping between entered usernames and activated user profiles, and you control whether the system accepts or rejects the supplied password. Sorry for being so obtuse...I go through cycles where it sounds simple, but then I read a particular phrase of documentation and I get the Fear(tm). So when you're in an exit program, you're already trusted by the operating system. So when you want to activate a particular user profile, you just specify it as an output parameter and don't have to worry about supplying its password. Is the FTP exit point abnormally flexible, or should I expect the same level of control for telnet signons, green-screen signons, database connects? Where _won't_ this model be applicable? -Jared On Fri, 6 Aug 2004 rob@xxxxxxxxx wrote: > > > Jared, > > I wrote my own ftp exit point program. I store the user id's and passwords > in a file. Length, etc OF MY CHOOSING. Then I swap to a different user > profile by simply changing a parameter on the ftp exit point. No swap > profiles api's are called directly by me. It's really quite > simple. Again, think, how else would you support anonymous ftp? > > Rob Berendt > -- > Group Dekko Services, LLC > Dept 01.073 > PO Box 2000 > Dock 108 > 6928N 400E > Kendallville, IN 46755 > http://www.dekko.com > > > |-----------------------------+-------------------------------------------| > | jared | | > | <jhunter@xxxxxxxxxxxx> | | > | Sent by: | To| > | midrange-l-bounces@midrang| Midran| > | e.com | ge | > | | System| > | 08/05/2004 04:04 PM | s | > | | Techni| > | Please respond to | cal | > | Midrange Systems | Discus| > | Technical Discussion | sion | > | <midrange-l@xxxxxxxxxxx| <midra| > | m> | nge-l@| > | | midran| > | | ge.com| > | | > | > | | cc| > | | | > | | Subject| > | | Re: | > | | Replac| > | | ing | > | | the | > | | AS400 | > | | signon| > | | manage| > | | r? | > | | | > | | | > | | | > | | | > | | | > | | | > |-----------------------------+-------------------------------------------| > > > > > > > > Depending on the interfaces you want to enable for this, it may be > > possible. What you are asking is for two different things. > > > > First, you want to authenticate with -- what to OS/400 is -- a "foreign" > > authentication mechanism. Second, based on the ID in this other > > authentication mechanism you want to choose the appropriate "local" user > > profile to run under. > > Exactly. > > > > As long as you control the interfaces (cleint and server) that are doing > > the authentication, then you can make this work. You have to change the > > client side that actually prompts the user for authentication > > In the retinal scan case, I think I'd only need to alter the FTP client > code if a retina scan is going to take longer than the client's connection > timeout. I could just have (it seems, DHCP issues notwithstanding) a > separate daemon on the client machine that responds to my server's > authentication requests. But to avoid that issue altogether, let's say I > wanted to use something more like SecurID, where a relatively > password-looking authentication string is being sent over the usual > channel, but the string bears no relation to the Password bound to the > relevant AS400 User Profile. > > In the documentation for the TCPL0300 exit point format, there appears to > be a relatively generic "authentication string" input parameter, but in > the documentation > > http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/rzaiq/rzaiql0300.htm > > it's written that "Note: for the logon to succeed, the authentication > string must match the user profile-supplied password." > > That really confuses me. If the password is "wrong" from the point of > view of the operating system, and the logon purportedly "cannot" succeed, > why is my exit program being called at all? If my exit program is being > called, I feel I should be able to access my JaredID two-factor auth > server with the authentication string as a parameter, get a response, and > do what I want. > > > The reality of the situation is that you probably don't own the > client-side > > code for at least some of the interfaces you would want to enable to use > a > > different authentication mechanism. Also, there is no approach that will > > work today for changing the behavior of a green screen sign-on from a > dumb > > terminal. > > Is there no exit point for green screen logon, or do you mean "any > approach that depends on special client software" (since, on a dumb > terminal, there IS no client software)? > > -Jared > > -- > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > or email: MIDRANGE-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. > > > > -- > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > or email: MIDRANGE-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. > >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
