In openUTM applications, services requested by terminal users or client programs are implemented by means of program units. These program units contain the openUTM calls and any database accesses that may be required. Different access privileges may be differentiated within an application.
openUTM offers two access control methods for this purpose which provide the same differentiation options but differ in the way they view the application’s objects:
the user-oriented lockcode/keycode concept and
the role-oriented access list concept
Lockcode/keycode concept
The lockcode/keycode concept enables you to ensure that only specially authorized users of client programs may use particular services of the UTM application. You can also specify that it is only possible to log on under a user ID via specific LTERM partners (connection points) or that particular services can only be started via special LTERM partners.
The objects to be protected - for example LTERM partners and the transaction codes assigned to the services - can be assigned a lockcode.
Keycodes are defined for user IDs and LTERM partners. When a keycode matches the lockcode of a protected object, access to this object is permitted.
A user ID or an LTERM partner can generally access multiple services and consequently has multiple keycodes. The individual keycodes are therefore grouped in keysets.
The lockcode and keycode concept has the following effects:
A terminal or client program can log on only if a keycode which matches the lockcode of the associated LTERM partner is allocated to the specified user ID.
A terminal user or a client program can call a service only if both the keyset of the user ID concerned and that of the LTERM partner contain a keycode which matches the lockcode of the transaction code.
Access list concept
When the access list concept is used, users are grouped according to roles or functions in the company (gate keeper, clerical officer, human resources officer, head of department, administrator, controller, managing director, etc.); a user can naturally have multiple roles. Each role is mapped to a keycode.
The administrator allocates one or more roles to each user of a UTM application (e.g. clerical officer, head of department, etc.).
For the objects to be protected - services and TAC queues - an access list is then used to define which user groups (clerical officer, controller, etc.) have access.
If, for example, you have selected Human resources officer as role 2 and Managing director as role 1, you can define that only these user groups should have access to the Personnel service by allocating the service an access list which contains codes 1 and 2.
The users involved are in turn allocated a keyset which contains all roles (keycodes) which a user may have.
If you also want to define that data which is relevant to security may only be accessed via particular LTERM partners, you must also allocate appropriate keysets to the LTERM partners.
Access to a service then requires at least one role which is contained in the service’s access list to be defined for both the user and for the LTERM partner via whom the user is logged on.
Effect on UDS/SQL
Irrespective of the access control method used, all openUTM users who have the same keyset (KSET) in openUTM form a user group in terms of their database privileges. The privileges for each of these user groups which work with the database via UTM transaction codes must be defined in the UDS/SQL databases by means of the BPRIVACY utility routine.
For further information on access control, please refer to the openUTM manuals.