Affiliation primarily determines the data to which the functions of the user’s job can be applied. The manager of the London branch may be able to perform exactly the same functions as the manager of the New York branch, but only on the data of London customers. Therefore, in systems terms, roles relate primarily to high-level access rights that are expressible in business language (e.g., raise an invoice). These are realized in the computer system as complex applications, application functions, or transactions. Affiliation determines which data objects the user may access.

In some servers, applications themselves cannot be guaranteed to confine access to the underlying data objects through the high-level operations that they are permitting for the role. In such cases, it is helpful to use roles also at an operating system level to limit the basic types of access that the user is to be granted (e.g., read, write) to the data objects that affiliation has identified.

Hard and fast rules cannot be set, but it is useful to take a view of these different properties so that when design choices have to be made they can be optimized for the most frequently encountered situations. What is important is that the role concept should not be extended to include controls that are due to affiliation. Most models fail to make this distinction (see the discussion of other role models later in this chapter), but it is an important one. Clearly, individual identity cannot be ignored as an access control attribute. Even in systems using job type and affiliation, an individual can be given special responsibility or may have personal data. Thus, a view of access control with three main dimensions, a sort of access control cube, is shown in Exhibit 2. Each cell of the cube would represent the access rights of a particular user with a particular job in a particular part of the organization.

Exhibit 2.  Access Control Cube

Despite this apparent three-dimensional complexity, it is important that, in most practical access control policies, for any one resource, if a user’s identity figures in the access control decision it is usually not used in conjunction with the other two dimensions — identity is adequate. Conversely, affiliations and roles are typically considered together; user identity is not involved. This point becomes important in considering the practicability of implementing such controls using access control lists.

The User’s View

In practice, not only can roles be used to constrain users, they can also provide users with clearly visible benefits. The basic idea is that users sign-on nominating a specific role that represents their job or current task, which results in desktops being presented that include only those services that are appropriate to this choice. When requesting access to a particular service, the sign-on role is also used to decide whether users can access that service. By limiting the desktop only to those services permitted by a role, users are prevented from surfing the distributed infrastructure in an attempt to access services they are not entitled to access. They also benefit from having a desktop uncluttered with icons in which they have no interest. The desktop is constructed only for their needs.

In practice, however, users rarely have well-defined jobs with clearly defined services, and a user’s desktop can vary in a number of ways — from the simple setting of preferences to the creation of personal icons associated with variations of particular applications (e.g., creating icons for specific spreadsheets). Users often have multiple roles and need to switch between them. Users work shifts and want the same role to be transferred between them and other users without being closed down. The security administrator may want to remove the right to use a particular service from the role of a particular employee, because he or she has yet to be trained in its use. Thus, in practice, the assignment of services to roles is more dynamic than those allowed by the classic models.

The use of roles to control the desktop frequently has three aspects, each with different implications for the application of security policy:

•  It must be possible for a user to create a personalized desktop. This allows users to decide which options are not security critical (e.g., foreground and background colors and position and content of program groups). These preferences should be available at whatever workstation the user signs on to, subject to the characteristics of the workstation permitting it.

•  Within their role definition, users must be able to extend their desktop with personal icons. For example, the user entitled to use the Excel spreadsheet should be allowed to create icons for individual spreadsheets created under Excel.

•  The security administrator must be able to change the content of a role definition for a particular user to account for local variations.

Beyond this, users must be able to switch roles dynamically and to attach, after suitable authorization, to an active role, even to extend an active role with additional components that are required to perform specific tasks. Role hierarchies help in this area.