The standard sign-on dialog is always performed when the following two conditions are met:
Automatic KDCSIGN (= automatic sign-on check) is not generated for the terminal (see "Automatic KDCSIGN").
No sign-on service is generated for the standard application name (generated in MAX APPLINAME) under which the user signed on (see "Sign-on process with sign-on services").
In the standard sign-on dialog, openUTM carries out a sign-on check (system access control). In the sign-on dialog, UTM messages in line mode ask the user for identification. In the UTM generation, you can choose between various variants and also modify the UTM message texts. However, this is the extent to which this procedure can be modified.
Different levels of freedom can be defined for the sign-on check. An overview of all options can be found in the diagram in the section "Scenarios for the UTM sign-on check".
openUTM outputs the following message to initiate the sign-on check:
K002 Connected to application <appliname> - please sign on
The user must verify his or her authorization by entering the following details:
KDCSIGN userID [,password]
The password can be entered in the KDCSIGN command if no password blanking is generated for this user ID (KDCDEF statement USER...,PASS=).
openUTM checks the user ID and the password (if there is one). If the result is negative, then the user is requested to re-enter the data for KDCSIGN. If the user is generated with a password, but the password has not been specified in the KDCSIGN command, openUTM requests the password in a blanked-out field in a second dialog step.
Blanking the password
If password blanking is generated for the user ID (KDCDEF statement (USER...,PASS=(password,DARK)), openUTM outputs a UTM message to ask the user to enter the password in a blanked-out field.
In this case, the user has the option of entering a new password to replace the previous one, provided the minimum validity period defined in generation allows the password to be changed at this time. In this case, the user must confirm the new password by repeating it. openUTM checks the old password entered and, if necessary, the new password. If the old password is incorrect, then the user is requested to re-enter the data for KDCSIGN. If the new password was not entered identically both times, a UTM message is output to inform the user and request that the data be reentered.
Validity period of the password
When generating the user ID, you can define a maximum and minimum validity period for the password:
USER ...,PROTECT-PW=(...,maxtime,mintime).
The minimum validity period means that the user cannot change his or her password until this period has expired.
The maximum validity period means that the user must change the password within the specified period.
If the password will become invalid within the 14 days following the sign-on procedure, openUTM warns the user in a K-message as long as a change is allowed at this time according to the minimum validity period for the password. A password can be changed as described under “Blanking the password”.
To prevent users that have not worked with the application for a long time from forgetting to change their password and then consulting the system administrator, the UTM application can be configured such that these users may sign on one more time after their password has expired, see section "Grace sign-on".
When the password is changed, openUTM checks the following:
whether the new password differs from the old one if a maximum validity period has been generated for the password.
If a password history is generated (SIGNON ...,PW-HISTORY=n), the new password is also checked against the last n passwords.whether the new password corresponds to the level of complexity generated for the user ID (USER ...,PROTECT-PW=).
whether the length of the password is greater than or equal to the generated minimum length (USER ...,PROTECT-PW=).
If the password fulfils all of these conditions, openUTM changes the password. The validity period of the new password again corresponds to the generated value.
If the new password does not satisfy one of these conditions, the following UTM message is output to ask the user to reenter the KDCSIGN information using the old password:
K097 Input for new password cannot be used - please sign on
If the validity period of the password has already expired when the sign-on attempt is made and if no grace sign-on is generated, the sign-on attempt is rejected with the following UTM message:
K120 Password expired - please sign on
It is not possible to sign on at the UTM application under this user ID again until the UTM administrator has assigned a new password to the user ID.
Grace sign-on
If the validity of the password has already expired when the user attempts to sign on and if the application is generated with grace sign-on (SIGNON ...,GRACE=YES), a K message informs the user that his or her password is no longer valid. The user is also asked to enter the old password and a new password. To change the password, a password must be reentered in the corresponding blanked-out field.
KDCSIGN with ID card
If the insertion of an ID card (magnetic strip card) is prescribed for the user ID in the UTM generation, openUTM outputs a UTM message asking the user to insert an ID card into the ID card reader. When this message is output, the keyboard of the terminal is locked. The lock is not released until the ID card is inserted. If no ID card is available, the keyboard can alternatively be unlocked with the K14 or ESC: key.
openUTM checks the ID card information, i.e. openUTM compares the character string defined in the KDCDEF statement USER ...,CARD=(...) with the corresponding character string on the ID card. If the result is negative, UTM message K031 is output to inform the user and request that the KDCSIGN information be reentered. If the result is positive, the user can work with the application.
The ID card must remain in the ID card reader for as long as the user wishes to work under this user ID. If the ID card is removed prematurely, openUTM detects this with the next dialog input or before, and implicitly generates KDCOFF. See also section "Signing off from a UTM application".
Scenarios for the UTM sign-on check
The following diagram shows the possible variants of the UTM-sign-on check, depending on the KDCDEF generation. If incorrect data is entered, openUTM outputs a specific UTM message and asks the user to reenter the information. If several unsuccessful sign-on attempts are made in succession from a particular terminal or under a particular user ID, openUTM outputs UTM message K094 with the standard destination SYSLOG (system log file). The maximum permitted number of unsuccessful sign-on attempts before UTM message K094 is initiated can be defined in the UTM generation with the KDCDEF statement SIGNON ... SILENT-ALARM=. An MSGTAC program unit can respond to this UTM message.
Figure 5: Sign-on check scenarios for applications with user IDs (part 1)
Figure 6: Sign-on check scenarios for applications with user IDs (part 2)
Figure 7: Sign-on check scenarios for applications with user IDs (part 3)