The following security functions are available in UTM:
System access control functions
These functions are available in openUTM by UTM user IDs and passwords of a particular complexity level. The functions are used as follows in CPI-C and XATMI:
The following calls are available in CPI-C:
Set_Conversation_Security_Type: define type of system access control
Set_Conversation_Security_User_ID: specify UTM user ID
Set_Conversation_Security_Password: specify associated passwordIn addition with UPIC
Set_Conversation_Security_New_Password: assign a new password
You must issue these calls before the conversation is established.
If sign-on was unsuccessful, the following call is also available after a Receive or Receive_Mapped_Data call:
Extract_Secondary_Return_Code: query the secondary return code
On the XATMI interface, the tpinit() call has parameters to activate these system access control functions (see tpinit - Initializing the client.
As soon as the CPI-C or XATMI program uses these calls, the system access control functions and data security functions outlined below become effective implicitly.
Data access control functions
In order to make certain services of the UTM server application accessible to a select group of users only, you can use the key code/lock code concept or the access list concept of openUTM (see the openUTM manual “Concepts and Functions”).
By means of the lock/key code concept lock codes can be assigned to the transaction codes (services) and the LTERM partners of the UTM server application. These objects can only be accessed by users or clients whose user IDs are assigned the corresponding key codes. At configuration time, a key set with one or more key codes is assigned to the user ID (USER ...,KSET=key-set-name). The key set defines which services of the UTM application can be accessed by the client.
In the access list concept roles are defined as key codes. The transaction codes are protected using access lists. One or more roles are assigned to each user ID (configuration statement USER ...,KSET=). A client may not access a service using a specific user ID unless at least one of the roles of the user ID is included in the access list. Roles can also be assigned to LTERM partners; the same then applies for access using an LTERM partner.
Data security through user-specific long-term storage area (ULS)
A user-specific long-term storage area can be assigned to each UTM user ID at configuration. This storage area can only be accessed by program units of the user/client as well as programs started by the administrator, whereby conflicting accesses are prevented by openUTM. The information in the ULS is retained even after the conversation is terminated. It is not deleted, but can only be overwritten by blank messages. The ULS is used to transfer data between conversations and the user’s programs.
A user-specific long-term storage area is assigned to each user ID of the UTM application with the KDCDEF control statement ULS.
Security functions in the client/server environment are implemented as follows within openUTM:
Before a UTM service is started, the authorization data coming from the client is validated and the corresponding UTM user ID is assigned, together with the associated key set. This corresponds roughly to a KDCSIGN of a terminal user immediately before the service starts.
Sign-on is still possible if the validity period of the user password has expired but the UTM application is configured with Grace Sign-On.
If the lock/key code or access list concept is used, openUTM checks whether the service may be started under this user ID and using this LTERM partner. If so, in the UTM service, the UTM user ID transferred from the client appears in the header of the communication area (KB header). The authorizations (key sets) linked with this UTM user ID apply.
The ULS block assigned to the UTM user ID transferred from the client can be used. If several clients sign on under one user ID, they share usage of the same ULS block, as there is only ever one ULS block for each user ID.
At the end of the service, the assignment (points 1 through 3) is canceled again.
Sign-on after expiry of the password validity period (Grace Sign-On)
If the UTM application is configured with Grace Sign-On, a client may still sign on to the application after expiry of the password validity period. If no sign-on service is configured for the UPIC client, the program is supplied with the return code CM_SECURITY_NOT_VALID after a Receive or Receive_Mapped_Data call. Additional information is supplied in the form of a secondary return code. If the password has expired, this code contains one of the following values:
CM_SECURITY_PWD_EXPIRED_RETRY if the application is configured with Grace Sign-On. In this case the program can set a new password using Set_Conversation_Security_New_Password at the next sign-on. The new password must differ from the old password but must satisfy the same requirements (length, complexity, use of special characters).
CM_SECURITY_PWD_EXPIRED_NO_RETRY if the application is not configured with Grace Sign-On. In this case the client user can no longer sign on using this UTM user ID. He or she must request the administrator of the UTM application to issue a new password.
The secondary return code of a Receive or Receive_Mapped_Data call can also be queried using a subsequent CPI-C Extract_Secondary_Returncode call. Extract_Secondary_Returncode supplies the secondary return code of the last Receive or Receive_Mapped_Data call.