RE: Replacing the AS400 signon manager?

Thanks for going into that level of detail...you answered some questions I
hadn't gained the perspective to be thinking about yet.  Progress.

So say I send a user into an initialProgram that performs an additional
authentication step, and then swap the active user profile for one with
more priveleges.  If the new user profile has the initial program and
initial menu fields set, are those settings honored when the
switch takes place?  My gut says no.  Is there a way to be in a running
program and say "hey, operating system, as soon as this program exits, run
this other program"?  The phrase "tail call" comes to mind.

The host servers, if I understand you correctly, make the second-stage
authentication difficult because they require access via a valid username
and password.  The exit doesn't get called until after the supplied
credentials have been verified using the standard mechanism.  So at that
point, secondary auth would depend on having another conversation with the
client, and depending on the type of client and how much we know about its
network location that could be either hairy or unfeasible.

What is a routing program?

Have a great weekend, everyone-

-Jared


On Fri, 6 Aug 2004, Kurt Goolsbee wrote:

> As far as the exits go and being able to set the identity that the job will
> execute under, the FTP server is the most flexible.  The logon exit is
> called prior the OS validating the supplied credentials.  I can't remember
> but I think this is the case for TFPT and for REXEC.  Because of the need
> for supporting the Anonymous user, the exit allows you to set the jobs
> identity to your choosing.
>
> For all of the host servers (Database, Data Queue, Remote Command...) your
> signon is validated before the exit is called and they don't have a return
> parameter to set the identity.  You can however do a swap.
>
> NetServer falls into the host server category above but is more of a pain in
> the rear end (I had to resend because the list bounced the email because I
> used the A word) because the server does not own the socket is using to
> communicate with.
>
> For Telnet, the exit fires prior to the user ever being presented a screen
> so you won't be able to prompt them for their secret.  You can't do a swap
> because this exit is called from one of the Telnet jobs.
>
> For telnet your best option is to either create a routing program or an
> initial program that you can do your extra prompting in.  These are also the
> only way to support what you want from a dumb terminal.  You do have some
> other things that you have to control - System Request menu and Attention
> menu access.
>
>
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of jared
> Sent: Friday, August 06, 2004 9:25 AM
> To: Midrange Systems Technical Discussion
> Subject: RE: Replacing the AS400 signon manager?
>
> > In order to get a clear idea of what you want, can you please provide
> > three scenarios of what your users should see? Describe telnet, FTP
> > and iSeries file transfer, and that might be enough for a reasonably
> > full response (perhaps close to what's reasonable as "full".)
>
> I really don't want the client software to change at all, in look and feel
> or underlying code.  But for some users, I want the "password" entered at
> the prompt to be characters that prove they know a secret that isn't the
> password stored with their AS400 user profile.
>
> On the server, I want that info passed into an exit program that talks to
> a secret-verifying service, determines whether to allow the signon, and
> continues the session under whatever user profile I want to map onto the
> username.
>
> So the out of band communication doesn't involve the client, just more
> server-side code that knows what to do with the non-standard auth strings.
>
> Is this only possible when logging in via some channels and not others?
>
> -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.
>
>