An access list is a number of access codes (numeric codes) that are assigned to a service. The access codes in the access list defines user access to a service and can be interpreted as the roles of the users within the structure of their organization (for example, general users, heads of department, system administrators).
If you use the administration tool WinAdmin or WebAdmin you can use meaningful names in place of numeric codes.
An access list is defined using the KSET statement and assigned to a service using the TAC statement. The roles for the user (USER) are also defined and assigned as a key set using a KSET statement. In the same way, it is also possible to assign an LTERM partner a certain number of roles.
A user can only access a service (TAC) protected in this way if both the key set of the user and the key set of the LTERM partner via which the user has signed on contains at least one of the roles that are contained in the access list of the service.
 | The differences between the lock/key code and the access list concepts are described in detail in the security function section of the openUTM manual “Concepts und Functions”. |
| KSET statement in section "KSET - define a key set" |
keysetname
Name of the key set or access list.
KEYS=
When assigning an access list to a service (TAC):
Specification of one or more roles (as numerical values) that have access to the service protected by keysetname.When assigning a key set to a user (USER):
Specification of one or more roles (as numerical values) that are to be assigned to the user.When assigning a key set to an LTERM partner (LTERM):
Specification of one or more roles (as numerical values) that may be performed when signing on via this LTERM partner.When using WinAdmin or WebAdmin you may also assign roles with alphanumeric names.
| TAC statement in section "TAC - define the properties of transaction codes and TAC queues" |
tacname
Name of the TAC.
ACCESS-LIST=
Specifies the access list that controls access to this TAC. Only users whose key set contains at least one of the roles contained in this access list and that sign on via a terminal that has also been assigned one of these roles may access this TAC. ACCESS-LIST may not be specified in conjunction with LOCK.
| USER statement in section "USER - define a user ID" |
username
UTM user ID.
KSET=
Specifies the name of the key set that the user ID is assigned to. The key set must be defined using the KSET statement. Each user can be assigned a maximum of one key set.
If a user wishes to access a service that is protected with an access list then at least one of the roles of the user must be contained in the access list. Otherwise access to the service will be denied.
| LTERM statement in section "LTERM - define an LTERM partner for a client or printer" |
ltermname
Name of the LTERM partner (only for LTERM statement).
LTERM= , NUMBER=
Name of the LTERM partners (only for TPOOL statement).
KSET=
Specifies the name of the key set assigned to the LTERM partner. For the LTERM partner of a UPIC client or a TS application without explicitly generated connection user ID this key set is the same as the key set of the connection user ID. The key set must be defined using the KSET statement. Each LTERM partner may be assigned a maximum of one key set.
USER-KSET= (only for TPOOL statement)
In LTERM pools, specifies the name of the key set for TS applications or UPIC clients that is assigned to the connection user ID. The key set must be defined using the KSET statement. The access authorizations are derived from the intersection of the key sets of KSET= and USER-KSET=.
Access to the LTERM partner may not be protected using access lists. When using access lists to provide data access control to services, you should not use access protection on the LTERM partner, or in other words the parameter LOCK of the LTERM and TPOOL statements may not be specified.
Data access control for service-controlled queues using access lists
It is also possible to protected service-controlled queues from unauthorized read, delete or write access. To do this an access list is defined (TAC/USER statement).
| TAC statement in section "TAC - define the properties of transaction codes and TAC queues" |
tacname
Name of the TAC queue.
Q-READ-ACL=
Q-WRITE-ACL=
Name of the access list that controls the read, delete and write access of a user to this queue. The access list must be generated using a KSET statement.
A user only has read or write access to the TAC queue if the key set of the user and the key set of the LTERM partner via which the user has signed on both contain at least one of the roles that are defined in the access list for the TAC queue.
The key set must be generated for the user and the LTERM partner using the USER or LTERM statements.
| USER statement in section "USER - define a user ID" |
username
UTM user ID.
KSET=
Specifies the name of the key set to which the user ID is assigned.
The key set must be defined using the KSET statement. Each user may be assigned a maximum of one key set.Q-READ-ACL=
Q-WRITE-ACL=
Name of the access list via which the user is able to protect their own USER queues from read, delete or write access. The access list must be generated using the KSET statement.
The owner of a queue always has read, write and delete authorization for their queue, regardless of whether the read/write authorizations are restricted for other users.
An external user only has read or write access to the USER queue of another user if the key set of the external user and the key set of the LTERM partner via which the external user has signed on each contain at least one of the roles defined in the access list for the USER queue.
If you do not specify Q-READ-ACL/Q-WRITE-ACL all users have read, delete and write authorization within the queue.
| For more detailed information on Message Queues see "Generating service-controlled queues". |