openUTM offers the following system access control options:
definition of logical access points for clients and partner servers
user IDs and passwords when using terminals
user IDs and passwords when using client programs
user IDs and passwords when using OSI TP partner applications (cross-application user concept)
system access control by means of ID cards when using terminals
use of Kerberos on BS2000 systems when using terminals
silent alarm in the case of repeated failed attempts to gain access
user-defined sign-on checks - SIGNON event service
| These options are explained briefly in the following sections. The precise format of the corresponding generation statements can be found in the openUTM manual “Generating Applications”. The KDCADMI calls are described in detail in the openUTM manual “Administering Applications”. |
Definition of logical access points for clients and partner servers
All clients and partner servers who wish to use a UTM application must be known to the application. This is achieved by assigning a logical access point to the client or partner server, which has been defined in the UTM application configuration.
LTERM partners - access points for clients
The logical access points for clients are known as LTERM partners (Logical TERMinal), and are generated using the KDCDEF statement LTERM. The KDCDEF statement PTERM (Physical TERMinal) is used to assign a “real” client to the LTERM access point. LTERM partners and PTERM assignments can also be defined dynamically while the application is running (KCADMI call KC_CREATE_OBJECT).
Figure 32: Connecting clients via LTERM partners
In the sample configuration in figure 32, clients A, B, and C can work with the UTM application. Although client D has a line to the server system, it cannot access the UTM applications, since it has not been assigned an LTERM partner in the application configuration.
If you wish, you can make this strict assignment system more flexible through the use of LTERM pools. LTERM pools allow you to provide a defined number of clients with access to the UTM application without explicitly assigning an LTERM partner to each client. If you use an LTERM pool, each client that wishes to connect to the UTM application and that has not been generated explicitly is automatically assigned an LTERM partner from the pool.
(OSI) LPAP partners - access points for partner servers
The logical access points for partner servers are known as LPAP partners (Logical Partner APplication) or, when using the OSI TP protocol, OSI LPAP partners. They are defined accordingly using the KDCDEF statements LPAP or OSI-LPAP. The KDCDEF statements CON (CONnection) and OSI-CON can be used to assign the “real” partner application.
Definition of user IDs and passwords
It is possible to define user IDs for UTM applications either during generation using the KDCDEF statement USER, or dynamically using the KDCADMI call KC_CREATE_OBJECT.
If a UTM application is generated with UTM user IDs, then it is possible to define user-specific passwords.
When defining passwords, it is possible to impose conditions, such as a minimum length and a certain level of complexity. You can also set the minimum and maximum validity period for the password of a user.
The passwords and user IDs are stored in an encrypted form by openUTM, i.e. they cannot be recognized in a dump. Passwords are transmitted in an encrypted form when communicating with clients and terminal emulations if they support encryption.
Users can change their own password while the system is running if a corresponding service has been created for the UTM application.
User IDs and passwords when using terminals
All terminal users who wish to work with a UTM application must identify themselves to the application by specifying their user ID. This sign-on check is also known as KDCSIGN. If a password has also been generated, then the password must also be specified.
Terminal users can change their password themselves when signing on (only possible for hidden passwords in UTM (BS2000)).
User IDs and passwords when using client programs
The openUTM identification and authentication concept is also available when using terminals and UTM client programs.
UPIC clients and OpenCPIC clients
UPIC clients and OpenCPIC clients transfer user IDs and passwords to the UTM application by means of special calls:
With CPI-C, the calls Set_Conversation_Security_User_ID and Set_Conversation_Security_Password are used.
With XATMI, the usrname and passwd parameters of the tpinit call are used.
When using UTM client with the UPIC carrier system, you can also change the password (Set_Conversation_Security_New_Password call). The client can determine whether the validity period of a password has expired by means of a return code.
Before starting a service, openUTM validates the authorization data transferred by the client, and assigns the respective user ID and the corresponding authorization profile (see "Data access control (authorization)"). This is similar to the KDCSIGN of a terminal user.
A single client program can thus run under several different user IDs with their own individual authorization profiles.
TS applications
The identification and authentication concept of openUTM is only available to you when using transport system applications if you have defined a sign-on service for this transport system access point (see "System access control (identification and authentication)").
The sign-on is valid for TS applications as long as the connection is available. When the connection is cleared, openUTM starts the sign-on service, validates the authorization data passed by the sign-on service, and assigns the corresponding user ID and the corresponding authorization profile for the duration of the connection.
If a client program does not transfer any authorization data, then a connection user ID permanently assigned to the LTERM partner is signed on. Clients with no protocols or interfaces for transferring authorization data (e.g. transport system applications) can thus access UTM applications - but only with a authorization profile of the connection user ID.
| Detailed information on the security concept when connecting client programs can be found in the openUTM-Client manuals. |
User concept for server-server communication via OSI TP
openUTM’s user concept is available globally in the context of server-server communication via OSI TP. When addressing the partner, you can select a security type in the APRO call:
N | (none) |
S | (same) |
P | (program) |
System access control by means of ID cards
The user IDs for a UTM application can be configured, such that a special ID card is required to access the application. For this purpose, a corresponding reading device must be available at the terminal. If the ID card is removed from the reader while the UTM application is running, openUTM shuts down the connection to the terminal. In the case of terminals with appropriate reading devices, access to the UTM application can thus be controlled by means of a user ID, a password, and a valid ID card.
Using Kerberos with openUTM on BS2000 systems
For terminals, openUTM on BS2000 systems together with SECOS permits the use of Kerberos (RFC1510). Kerberos is network authentication protocol developed at the Massachusetts Institute of Technology (MIT). It is a security system based on a cryptographic encryption schemes. When using Kerberos for authentication, passwords are not passed as plain text over the network. This prevents passwords from being intercepted in the network. Furthermore, there is no need to administer the passwords for a user for different applications, i.e. Kerberos permits a single sign-on for different applications.
Kerberos works with symmetric encryption, which means all keys are available at two locations; one with the owner of a key (principal) one at the KDC (key distribution center).
Silent alarm in the case of repeated failed attempts to gain access
Following several consecutive failed attempts on the part of a client or OSI TP partner to sign on to a UTM application, openUTM sends a message internally to the default destination SYSLOG (system log file) or to MSGTAC (optional) to signal the possibility of illegal access attempts. The sign-on attempts of a user do not need to be performed on the same client. Unsuccessful user sign-on attempts can therefore also be monitored when access is performed via a terminal pool.
You are thus given the opportunity to take appropriate measures, e.g. sign off the connection by means of automatic administration (see "Automatic administration"). In the configuration, you can the define the number of permitted failed access attempts, after which this message is to be generated.
Automatic close of connection
During generation, you can define the maximum time that the UTM application should wait for terminal input after the end of a transaction - or after dialog output during a transaction. If no data is entered within this period, then the connection to the client is cleared down. If the client is a terminal, then a message is also output. If terminal users forget to sign off from the UTM application after completing their work, for instance, the automatic timeout mechanism reduces the possibility of unauthorized access to the UTM application.
User-defined sign-on checks - SIGNON event service
When signing on to a UTM application, predefined UTM messages are output by default requesting the terminal user to enter a user ID and password, and if necessary, to insert an ID card.
However, you can use the SIGNON event service to customize the sign-on dialog for your application, and to introduce your own authorization checks to supplement those of openUTM. You can define multiple SIGNON services and thus design sign-on services specifically for particular types (terminals, clients with the UPIC carrier system, transport system applications, etc.).
openUTM supplies sample programs for a SIGNON service - both the compiled objects and the COBOL sources. This SIGNON service, which implements a sign-on dialog with formats, can be used without modification or adapted for your own dialogs.
| Information on how to program and operate SIGNON services can be found in the openUTM manual „Programming Applications with KDCS”. |
