|
> 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
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.