5250 SSO ( was RE: Tying in biometric scanning to 5250 sign on )

midrange-l-request@xxxxxxxxxxxx wrote:

>   7. RE: RE: Tying in biometric scanning to 5250 sign on (Chris Bipes)
>
>I see you are right again.  It's the application that performs the 5250
>data stream manipulation.  Now how can I use SSO with a twinax terminal!
>;-) But is there a 5250 terminal that supports biometrics?  Ok we are
>moving away from them so I really don't need any.  Also we have removed
>90% of our twinax and have been using Ethernet thin clients with 5250
>emulation.  Now those could be updated to support biometrics and SSO I
>suppose.

Chris:

I haven't specifically looked at twin-ax as a player within SSO, so I'll need 
to dig to see what shows up (_if_ anything; I work here but not much w/SSO). 
However, this is a possible example of how secondary interactive subsystems and 
named devices (or relevant exit points) can come into play.

A direct-attach twin-ax terminal isn't quite so vulnerable to password sniffing 
via network hacking. It can be isolated into a subsystem that still displays 
profile/password entry fields. This might be done via appropriate ADDWSE 
commands.

And bypass-signon isn't exclusively tied to Kerberos/SSO. Technically, with the 
"right" exit programming, it could use any means that _can_ be programmed 
including not requiring nor relying on the entered profile/password at all 
which can obviously bring serious security risks.

In general, there are three options that can help within "bypass-signon":

1. Telnet/TN5250x over SSL with encrypted connection,
2. TN5250E with password encryption, and
3. Telnet/TN5250x within a SSO framework where "password" isn't sent as part of 
the connection.

(...where TN5250x can be just about any telnet that works; for SSO, it gets 
limited. Note that OS/400's TELNET command parameters support TN5250E outbound 
nowadays.)

Various combinations of subsystem definition, exit programs, routing programs 
and configuration elements such as SSO enablement can be used to make any or 
all of those work concurrently.

>From your perspective, it ought to be clear which elements you should use and 
>how each should be used. But it likely isn't clear. Any significant security 
>endeavor will be more complex than we would like.

We can mostly all get by with databases that are less than ideally defined. We 
can get by (and prosper) with programs that haven't been written to the highest 
standards and maintained with strictly controlled change-management and 
compiled with all of the appropriate settings and optimized to the best 
possible level. We can get by fine without system cleanup functions that 
automatically remove every unneeded object and reclaim each stray byte.

But security... If a system is network accessible and it is holding or can 
access critical company assets, those in charge of the security better be 
better than anybody else who has access to the same network and they better 
_implement_ accordingly.

In short, security just _can't_ be relegated to "it works good enough" status. 
It isn't trivial nor easily mastered, especially when there are important 
elements that aren't widely publicized if published at all (aside perhaps from 
possible 'Integrity problem' PTFs once in a while).

For AS/400s, iSeries or i5s in a Windows network, the issue mushrooms 
dramatically. (Not to mention bits of the UNIX world that have been touched 
here and there.)

<vendor plug - you knew there had to be one>

If you haven't already, contact an iSeries/i5 SSO solutions vendor. At the 
least, get a dialog going and see if there are tools that can help to examine 
your system and network to find out something of the scope that needs to be 
addressed. ( http://www.powertech.com ) Sales guys can be an irritant, but they 
can also be a resource when they're hungry.

</vendor plug>

Tom Liotta

>-----Original Message-----
>
>5250 can be run in a compliant way. 5250 itself need not be compliant;
>only the usage needs to be compliant for SSO.
>
>For example, if your interactive subsystem(s) throw up a signon panel
>that has no input fields but only text saying that entry without prior
>verification is forbidden, the Kerberos/SSO solution becomes more easily
>enforced. Or TN5250e with encrypted password perhaps. Or however you
>choose to configure things.
>
>(You could have a secondary interactive subsystem that could be used
>when needed and that allowed terminal signon panels.)
>
>In short, _you_ choose whether or not a given technique is used. SSO can
>work fine with 5250.