A sign-on service for terminals is generally made up of two parts:
Sign-on service | |
Part 1 | Part 2 |
The service asks the user for identification, reads the authorization data with MGET, and transfers this data to openUTM for checking. The service is not yet assigned to any user ID. | openUTM has accepted the authorization data and has assigned the sign-on service to the established user ID. |
Between the first and second part of the sign-on service, openUTM can - if necessary - insert an intermediate dialog that is controlled by openUTM messages. This intermediate dialog reads a magnetic strip card or a password generated with USER...,PASS=(...,DARK). In these cases, openUTM asks the user to enter this information, as in the standard sign-on dialog. This procedure offers the users additional security for accessing their applications. In the intermediate dialog, it is possible (as in the standard sign-on dialog) to replace the previous password by a new one.
Special cases of the sign-on service for terminals
The sign-on service must be changed accordingly for the UTM generation of LTERM partners with automatic KDCSIGN and for signing on via OMNIS.
LTERM partners with automatic KDCSIGN
The sign-on service receives the information that the user ID is already known to the system when calling SIGN ST. An intermediate dialog can now be run to query a magnetic strip card or a password.
Signing on via OMNIS or multiplex connection (OMNIS)
When the user signs on to the UTM application via multiplex connection, then OMNIS transmits the authorization data on to openUTM via the PUTMMUX protocol for further verification. If the data is correct, then openUTM starts the sign-on service that contains the appropriate information from the SIGN ST call. If the data is incorrect, then the sign-on service is not started and the distributor must inform the user on the terminal.