When the access list concept is used, users are grouped together by their roles or functions within the company (porter, clerical worker, personnel worker, head of department, administrator, controller, chief executive officer, etc.). A user can, of course, have more than one role. Each role is mapped to a key code.
The administrator assigns each user of a UTM application one or more roles (e.g. clerical worker, head of department, etc.).
The access list is then used to specify which user groups (clerical worker, controller, etc.) have access to the objects (services and TAQ queues) to be protected.
If you have defined “personnel worker” as role 2, for example, and “chief executive officer” as role 1, you can specify that only these user groups are to have access to the “Personnel” service by assigning the service an access list containing the codes 1 and 2.
You assign the user a key set that contains all the user’s roles (key codes).
If you use the WinAdmin or WebAdmin administration tool to define access lists and key sets, you can also use meaningful role names instead of numeric codes (UTM converts these symbolic names internally into numeric codes).
LTERM partners can only be protected by means of a lock code. When you use access lists, you should, however, do without the additional data access control of the LTERM partners by means of lock codes (i.e. you should not specify the LOCK operand of the LTERM or TPOOL statement). By assigning a suitable key set to the LTERM partner, you can still ensure that it is only possible to access security-relevant data via particular LTERM partners.
This variant also has the advantage that the key codes in the key set of the LTERM partner do not have to be in the key set of the user. A number of key codes can thus be reserved in an application for access via LTERM partners, for example, because, when a service is accessed, it is enough if only one of the roles of the accessing user is in the corresponding access list, and one of the key codes of the LTERM partner.
If you want to protect a service or a queue by means of an access list, you have to:
define the access list by means of the KSET statement
assign the access list to the service or queue by means of the ACCESS-LIST operand of the TAC statement
define the user-specific key sets by means of the KSET statement
assign the desired key set to the user by means of the KSET parameter of the USER statement
If you also want to specify that access to security-relevant data is only possible via certain LTERM partners, assign these LTERM partners the appropriate key sets by means of the KSET parameter of the LTERM or TPOOL statement.
A service or TAC queue cannot be accessed unless both the user and the LTERM partner via which the user signed on have at least one role in the access list of the service or queue.
Personnel administration example
In this example, the following roles exist for users and LTERMs:
1: Chief executive officer
2: Clerical worker
3: Telephone operator
10: LTERM with high security level
11: LTERM with normal security level
The application has the services PAYROLL (payroll accounting), PERSDATA (for editing personnel data) and PHONE (for obtaining telephone lists).
This can be illustrated as follows:
Figure 34: Data access control with the access list concept
A user can only start a service when the key set of the user ID and the key set of the LTERM partner via which the user signs on contain a key contained in the access list of the service:
The user SMITH is the chief executive officer and the only one permitted to call all the services. To access the PAYROLL service, for security reasons he must sign on via the client that is assigned to the LTERM partner LTERM1.
The users JONES and HARRIS are personnel clerical workers and can call the PERSDATA and PHONE services (via any LTERM).
The user KELLY is a telephone operator and can only access the PHONE service.