Re: Replacing the AS400 signon manager?

[jared <jhunter@xxxxxxxxxxxx>]

> 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