A Simple Example

Exhibit 4 demonstrates an example of how ACLs may be set up and mapped from incoming PAC attributes. The scenario is a hospital with two wards. Nurses in either ward are required to use the same nursing support application. By using this application, they should be able to view patient data in the other ward, but should only be able to modify the data for patients in their own ward. Control of the individual ward’s data base lies with each of the two ward administrators.

Exhibit 4.  Example of Role and Affiliation Mapping

The enterprise management view is very simple, and it is a view that can easily be reflected in the actual engineering representation:

•  An administrator has the role of ADMIN; a nurse the role of NURSE.

•  Any Ward 1 person has an affiliation of WARD1.

•  Any Ward 2 person has an affiliation of WARD2.

When a PAC is received at the server, the following steps are taken:

1.  The role attribute is used to determine whether the application requested by the user is accessible, so that nurses in both wards have access to the same nursing applications and administrators to the same administration applications.

2.  The mapping logic is examined, as shown in Exhibit 4, which results in the following:

•  An administrator’s application operating under the UID owning the data file of that administrator’s ward. This UID has no access to the data file from the other ward.

•  The nursing application operating under a group appropriate to the nurse’s ward. This group has read access to the data file of the other ward. The UID under which the application operates has no access in itself to the file concerned.

Note that the affiliations in rows 3 and 4 of the mapping table could have been mapped onto a UID instead of a group (e.g., WARD1 could have been mapped to UID3 instead of G1, and UID3 put in the ACLs instead of G1). In this case, the application would have had to run under UID3. The difference lies in the access rights established for objects now created by the application, which in the UID3 case would be effectively owned by the ward with which the nurse is affiliated. In the example case, objects created are owned by a UID that can be chosen using other policy criteria. Either mapping choice could be appropriate depending on requirements.

ROLES IN ACTION

The following examples have been drawn from actual experiences. The names of the companies have been omitted. These illustrate the extent to which a straightforward RBAC policy should be flexible to account for the complexities of modern business organizations and for the needs of the individual end-user when the role is also used to define the user’s desktop. Much of this complexity affects the way roles are managed rather than the way in which they are used to simplify the access decision function in target systems.

A construction company — This company has many project managers, all of whom use the same applications and services, but each of whom is allowed only to access the files relating to those projects for which he or she is responsible. This fits very well with the access control cube model, with the project manager as a role and the specific data sets as affiliations.

A government department — This entity has created generalized roles, but removes access to specific applications for individuals, because they have yet to be trained in their use. In addition, each user has a list of desktop applications from which those the individual wants can be selected (i.e., each individual is permitted to access a subset of the global set of desktop applications defined for a role). This setup illustrates the necessity of tailoring a general role to specific user needs, thereby avoiding many almost identical roles.

An educational organization — This organization has created role hierarchies along the lines described in this chapter. For example, a student role has been created, as well as a teacher role that includes the student role.

A multinational systems integrator — In this case, users need to be able to create icons representing particular instantiations of desktop applications (e.g., particular Excel spreadsheets, Word documents, or Powerpoint presentations). In this situation, the access control policy is not being violated, but users are being allowed to tailor the desktop to their particular needs within the access control policy set down for that role.

A hospital — On a ward, many nurses would like to use a workstation to prescribe drugs and other medicines. The workstation is signed on at start of day in the role of nurse, but for each prescription the specific nurse must be specifically authorized as part of the task protocol. An alternative in which each nurse signs on and signs off would create an overhead of closing and recreating the desktop for each nurse, which would take an unacceptably long time.