Although the access control concept that was previously employed is clearly extremely powerful (protection mechanisms of any level of complexity are possible), it is nevertheless somewhat confusing for users.
On the one hand, this is due to the exclusive use of numbers for lockcodes and keycodes at the UTM interfaces (configuration, administration).
On the other hand, at the time of UTM generation it is necessary to decide which services particular users are to be permitted to access. However, it is frequently easier to view things from the opposite direction: which users should be allowed to access this service?
The "new" access control concept takes this as its starting point.
This concept introduces the idea of "roles". It is possible to assign one or more roles to each user (e.g. "manager", "clerk" or "caretaker"). If you want to control access to a particular service then you set up an access list for this service. This access list in turn contains one or more roles. Only users who are assigned at least one of the roles in the list are then permitted to access the service. For example, the access list for the "Payroll" service might contain the roles "manager" and "payroll clerk" since all department managers and payroll clerks are to be allowed to use this service, whereas caretakers are not.
This concept is largely based on the "old" lock/key concept: the keycodes/lockcodes simply need to be interpreted as roles. Any given keycode/lockcode corresponds to a specific role (e.g. the code "1" might correspond to the role "clerk").A keyset thus corresponds to a role list or access list.
The definition of user or coupler authorizations in the form of role lists thus corresponds to generating a Kset for the user and coupler objects.In order to permit the definition of access lists for services, the generation statements for the Tac and Lac object types have been extended to include the ACCESS-LIST parameter which makes it possible to assign an access list in the form of a keyset.
To keep the new concept as simple and clear as possible, no access lists are assigned to couplers. The LOCK parameter for Lterm and Tpool couplers continues to be supported for reasons of compatibility. However, it is advisable not to assign any lockcodes to couplers. Although this means that all the couplers are then unprotected, this does not matter since it is not the couplers themselves but the services in the form of Tacs and Ltacs that are the resources that need protection.
Thus, in the new concept, users can only access a service if
- they have a role that is stored in the service's access list or the service is unprotected
and - the coupler that is used has a role that is stored in the service's access list or the service is unprotected.
This concept is supported by WebAdmin as described in the following sections.