In the preceding we have presented a general, yet concise, framework for modelling roles within an organization. The framework can be used to describe various applications of the role concept.
Sandhu and colleagues have identified a number of important issues to be considered when designing a system to use role-based access control [SCFY94,SCFY96]. These issues include Role definition and administration, Assignment of users to roles, Assignment of privileges, Role hierarchies, Constraints, and Role use. In the following we shall examine how our framework can be applied to handle these issues.
In our examples, we will revisit the Acme General Hospital ward introduced in chapter 1.
Our framework implicitly defines at least three necessary logical information repositories. The Role repository provides other parts of the system with information about roles, their users and other information present in the RDO. The Organizational relations database contains information about the relations used to structure roles. In addition, there must also exist a User database that maintains unique user description objects for each user in the system. Which roles and relations that are to be defined depends on the organizational structure and policy.
In our example, the system designers at Acme General, after having carefully studied a typical ward in operation, arrived at a design consisting of seven roles and one pseudo-role (pseudo-roles are roles without a direct relation to any job function, see further section 4.3.4). Figure 4.1 shows these roles and also how they are related in an is-a hierarchy.
Figure 4.1: Roles at an Acme General Hostpital ward.
It is often a complex task to analyze an organization in order to find the roles and relations that accurately model it. Using our framework to represent the model can help structure this work. In the case of RBAC, the explicit separation of the role definition from role use makes it natural to let the organizational structure govern the grouping of access privileges.
An important motivation for RBAC is that the static security structure provided by roles simplifies the administration when users join, move within, or leave an organization. However, in large organizations the sheer number of roles and users may make centralized administration cumbersome. To alleviate this situation the authority to add or remove users to/from roles can be delegated in a controlled manner. In our Acme example the head physician is responsible for maintaining a duty roster that for each week assigns individuals to the various positions in the ward. It is also conceivable that the head physician further delegates some of this responsibility to the head nurse.
The task of assigning access privileges to roles can often be delegated as well. One should, however, keep in mind that this is a task separate from that of assigning users to roles. In many cases, these two tasks are performed by different roles.
Identifying which roles to use is a complex task, as is identifying what access privileges can be assigned to a role. A problem is often to find an appropriate granularity for the kind of operations that can be controlled in the access control system. If granularity is too detailed, manageability and overview are lost. On the other hand, if granularity is too coarse, it might not be possible to enforce all access control policies.
Given a set of roles and a set of operations, it is possible to create an access control structure. In our framework, only assignment of users to roles is expressed directly, assignment of privileges to roles must be realized through the application data entity in the role descriptor object. Abstractly, the privilege information is viewed as being stored within the RDO.
In figure 4.2, we show a simplified version of the access control assignments at our Acme General ward. There are several underlying policies for these assignments, the most important being those concerned with assuring the confidentiality and integrity of patient record data.
Figure 4.2: Hospital ward access assignments.
Many security policies cannot be directly expressed in terms of access privileges to system resources. In RBAC, restricting rules or constraints can be introduced at several levels. In order to avoid confusion it is important to identify the kind of constraints being discussed. We identify the following three main categories of constraints:
One important constraint policy is separation of duty that mandates that two roles must not have any common role users. An often cited example is that of a payment that must be authorized by two different roles, e.g. clerk and supervisor, to minimize the risk of fraud. Obviously, the purpose of this policy is nullified if a user can take on both roles. The separation of duty constraint policy can be implemented either statically or dynamically. In the static case, the constraint is placed on the organizational model, a user can only be assigned to one of two roles to be kept separated. In a dynamic implementation, a user can be assigned to both roles; however, for one and the same same user, the roles can only be active one at a time.
There are also several other types of constraints, as mentioned by Sandhu and colleagues [SCFY96]. These include cardinality constraints that can be used to limit the number of users that can be assigned to a role and session constraints that restrict the ways in which a user can activate roles.
In our framework, inter-role relations can be used to express
static constraints. Mutually exclusive roles can be expressed as related
through a symmetrical, anti-transitive, and anti-reflexive relation.
This relation can be expressed as a list of pairs
,
e.g. 
. The relation is
anti-transitive, thus a user may take on both roles 
and 
(as 
is not in the relation).
At the same time, a user assigned to 
must neither be assigned to
nor 
. In some instances it may be required to generalize
this binary relation to encompass three or more roles.
Simple cardinality constraints may be expressed using unary relations by defining one relation for each cardinality. This, however, is an awkward approach. There are also other constraints, such as time limitations, that are difficult to express as general relations. For constraints that do not involve other roles it therefore seems more appropriate to place such constraint information in the application data block.
Apart from a method to describe constraints, there must also be means to enforce them. How this is achieved in detail is implementation specific. Still, a few general observations can be made.
Given an organizational model, static constraints can be seen as assertions about the model. A model in which all constraints are satisfied is called consistent. A way to preserve consistency is to check that changes to the model, such as the assignment of a user to a role, do not cause any violation of the constraints. The addition of new constraints is more difficult to handle. Imposing a new constraint may affect many roles in the model and have unforeseen ramifications. Therefore, there must also be a method for checking the consistency of an entire model.
To enforce dynamic constraints on role activation we introduce the concept of a user session. A user session provides a secure user interface to a system and is managed by a trusted session manager. When a user asks the session manager to activate a role, the session manager is responsible for checking applicable constraints before granting the access. Examples of such constraints are those that impose restrictions on which roles a user may have active simultaneously and constraints that put restrictions on the time of day a user may activate a role. One constraint is always checked; the user requesting access has to be listed as a role user.
Constraints on role use lie within the scope of operations of the access decision function in a system (see section 6.3.1). The decision function can take into account various contextual information and decide to allow an active role to access a target only under certain circumstances (satisfying all constraints).
As we have seen, when looking at how constraints can be enforced, it is natural to make a distinction between constraints on the static properties of the organizational model and constraints on the actual use of roles. This categorization is only one of many possible. Figure 4.3 schematically illustrates some possible categorizations. One such categorization is that of inter-role constraints vs. single role constraints, e.g. mutually exclusive roles compared to cardinality constraints.
It is also possible to classify along the axis of what is constrained by the constraint. Mutually exclusive roles constrain the assignment of users to roles, whereas time limitations constrain the use of a role. Yet another category would be constraints on privilege assignment to roles.
Figure 4.3: Different categorizations of constraints.
As we have seen, given a set of roles, we can within our framework introduce relations among roles to help structure the organizational model. Relations that introduce some kind of hierarchical structure among roles constitute an important class of relations. We can identify at least three important kinds of hierarchical relations:
Even though all three kinds of relations can be found within an organization, there is very seldom a one-to-one mapping between them. For instance, a company president would be senior to everyone in an organization, however, the role would most probably not be a specialization of every role, e.g. the company president is not an electricity technician. Another example is pseudo roles (discussed by Parker and Sundt in [PS95]). When using roles to group access rights, it is often natural to introduce a role with the sole purpose of being a container for access rights common to a number of other roles. A pseudo role of this kind does not correspond directly to any role in the ``real'' organization.
In the literature, the different kinds of hierarchical relations are not always kept separate. For instance, Nyanchama and Osborn have proposed a model where roles are organized into a lattice. The lattice is based on a `` junior-senior'' relationship that implicitly suggests an organizational seniority relationship. The lattice is defined purely using set inclusion of access rights [NO94].
Within our framework, it is possible to represent all of the different kinds of hierarchies. However, we do not believe that organizational seniority relationships should be used for inheritance of access rights, as doing so can lead to an undesirable concentration of rights at the management level. On the other hand, to identify and chart this relation is important in order to understand an organization. Such understanding is essential in the policy making phase of the security process.
Once security policies have been established, specialization and explicit inheritance relations can be used to create a structure within an organizational model that is efficient for access control purposes. Keeping the distinctions we have made in mind, inheritance
relations among roles can help reduce the number of explicit privilege assignments and can also provide a better overview of access control information.
We discuss here the relations for inheritance of access rights among roles together with a definition of the set of effective rights for a role. We start by making some definitions:
Let 5.95mm
For brevity, where a role r is implicit, we will write 
and
to denote 
and 
respectively.
The function 
is defined in the following manner:
where
and
The set 
of effective rights for a role is defined as 
.
In prose terms, this means that if role a inherits-from role
b (
), then the privileges assigned to role b
are inherited by role a. This process is repeated for each role
a inherits-from. However, any privileges that role
b might have inherited are not transfered to role a.
In addition, rights can also be inherited through the transitive
relation 
.
Figure 4.4: Privilege inheritance.
Figure 4.4 (a) shows a simple example where privileges are inherited using the inherits-from relation.
If some roles are specializations of other roles, for instance
electricity-technician --- technician and company president ---
manager, we can take advantage of this structure and avoid having
to repeat the link to the pseudo role employee. We do this by
using the transitive inheritance relation, includes-role, denoted
.
Figure 4.4 (b) shows the same rights being inherited as in
(a), but expressed using 
.
The relation 
can be
expressed in terms of I.
However, use of 
can reduce the number of explicit links in
the model. The two notations can be combined, as in figure
4.4 (c). Here, the role manager is specified to
inherit the privileges assigned to the role technician.
We believe that role hierarchies for the purpose of access control should primarily be seen as administrative tools that are not visible to the user. By defining role hierarchies it is possible to avoid having to duplicate the assignment of access rights to similar roles.
In section 4.3.3 we introduced the concepts of user session and session manager. The session manager handles the dynamic side of RBAC that arises when users take on and relinquish roles. We have not yet included these entities into our framework in a formal way.
The primary task for the session manager is to grant access to roles and to convey to the user the privileges associated with these roles. As we have mentioned, granting role access involves checking a number of constraints, the basic one being that the user should be listed in the list of allowed users for the role.
The nature of the privileges granted to a user varies greatly among implementations and organizations. For instance, there is a large difference between a centralized and a distributed system. A centralized system can implement an access server that mediates all access to protected system objects, whereas in a distributed system privilege information has to be conveyed to remote applications.
We have observed that to maintain an organizational model created within the framework, a number of databases are necessary. In order to maintain the consistency of the model it is necessary to mandate that access to these repositories must be through an API of primitives that operate on the model. These primitives can then be designed to guarantee to maintain consistency.
There are a number of issues to be addressed in this design. For instance, as individuals in an organization in many cases have several responsibilities, it is often desirable that a user is able to acquire, and act in, the capacity of several roles. This raises the question of how a user should go about acquiring and relinquishing roles. To acquire a new role, the user can make a request to the system using her previously authenticated identity. Alternatively, the user can renew authentication, specifying the desired role.
Another issue is how a user should go about relinquishing a role. This can take place voluntarily, but security policies may require a role to be relinquished at some point, regardless of the principal's wishes in that respect. An example is when there is a policy of separation of duty. Here, the policy mandates that a principal cannot act in role a at the same time as it also can act in another role, b. If roles a and b both are assigned to a principal, the system must assure that role a is relinquished whenever role b is acquired, and vice versa. Separation of duty may also be enforced through a policy stating that a principal must not be assigned to both roles. This, however, is a static constraint on role database contents, not on role usage.
To implement mechanisms that guarantee that a role is relinquished when mandated can be difficult. This is because in distributed systems, information about activated roles is often passed to a principal in the form of an autonomous Privilege Attribute Certificate, PAC (see section 3.2 and 3.3.) After a PAC has been issued, the security attribute server no longer has access to it. To work around this problem, the PAS can maintain a list of PACs that have been invalidated. In order to enforce policies such as separation of duty, servers would then always have to check whether a presented PAC is still valid, something that could introduce substantial overhead in the system.
Another approach is to introduce an entity such as the context manager proposed in the architecture of chapter 3.
Examples of policies mandating privileges to be relinquished at a specific time are, for instance, policies that restrict the times when a role can be activated to certain time periods. Such limitations are relatively easy to enforce by limiting the time of validity of a PAC to conform with the policy.