Representing roles

Using roles as a descriptive tool for expressing policies and other organizational information can be very effective. In order to use such information in a computer system it must somehow be represented. In this section we present a flexible framework for a representation that has several important merits. Our framework provides a general way of modelling organizations by using roles and inter-role relations. Apart from being suitable for building models of organizations for use in information systems, we believe that the framework is a useful tool for analyzing organizations themselves as well.

Requirements for a role representation

To be able to put roles into a broader context, the representation of a role within an information system must allow for more than just privileges and access-rights. What are the requirements for such a representation? Apart from general requirements, such as extensibility and modifiability, commonly found in Software Engineering, we have identified the following general criteria

Formal foundation.

In order to be able to make any predictions at all about whether or not a given role framework meets specified security goals and policies, it must be possible to reason about roles. This requires a formal notation as well as a set of rules and an inference machinery.

Generality.

The model should be able to capture a wide range of facets of the role concept. We feel that roles are a powerful tool for describing organizations and that such descriptions have several uses besides that of access control. For example, Lupu and colleagues have made a strong coupling between organizational policies and roles [LMSY95].

Scalability.

Any general framework runs the risk of becoming very complex in order to achieve completeness. To prevent role descriptions from becoming unwieldy, it must be possible to omit from an instantiation those parts of the framework that are not applicable to a particular case.

Applicability.

In many cases, RBAC can be used to describe existing security policies. Role-based security schemes can also often be implemented, or emulated, using existing tools and mechanisms. It should be possible to apply a role description framework to these cases, too. By allowing for legacy systems in the framework in this way, comparisons between present and proposed systems become possible.

A role description framework

As mentioned when defining the role concept in section 4.1, there are two main components in any role description, the role function and the relations the role has to other roles. For roles to be meaningful, it must also be possible to assign users to roles. In addition to these components, it should be possible to associate application data with the role description. In the case of RBAC this may consist of privileges and permissions given to the role.

In this section, we present a framework that meets these requirements, as well as most of the general requirements identified in section 4.2.1. The complex task of providing the inference rules and machinery needed for automated reasoning about roles is subject to research.

The Role Descriptor Object

The basic entity in our role description framework is the Role Descriptor Object (RDO). The RDO is a representation of the external role concept used within the information system and contains the information associated with a role. We define the RDO to be 4-tuple where

 ¯Fis a  function description for
  the role

  		R  		is an entity describing the  relations the role has to other roles

  		A  		is a block of  application data associated with the role

  		U  		is a list of  users  assigned to  the role.

Function description

The size of the final organizational model depends greatly upon the granularity with which role function descriptions are made.

Taken to one extreme, it would be possible to allot a role to each task to be performed within an organization, resulting in a multitude of roles of type performer-of-task-x. This fits poorly with our given definition of a role, and would also be very cumbersome to administrate.

At the other extreme, we could try to make our role descriptions as general as possible in order to reduce the number of roles, and thereby also the administrative effort. Again, the resulting roles may fail to reflect the true organizational structure. For instance, although having only one job, many persons serve their organization in several different capacities.

Obviously, the exact granularity and extent of a role function description is highly dependent on the demands of the organization of which the description is a part. We believe that this judgment in practice will come naturally, provided the underlying organizational structure is well understood.

As it is hard to make any statements regarding the extent of the function description; it is also hard to enforce any specific structure to the description. At this stage we do not go further than to specify the function description attached to the RDO to be a textual one, intended for human readers.

Relations between roles

As the name suggests, positions within an organization are defined in terms of how they relate to other positions. A common relation of this kind is the supervisor-subordinate relation.

There may also be other relations between the roles in an organization. By using these relations it is possible to get other views of the organization. Lupu and associates mention several classes of such relations; client-server, contractual, collaborative, and peer-to-peer [LMSY95].

For each relation introduced into an organizational model, there must be a relation specification that describes properties of the relation such as name and type.

The designated type of any relation imposes constraints on how objects can be related. For example, ordering relations are anti-symmetric and generate graphs that are free from cycles. Symmetric relations, on the other hand, require that iff .

There are many ways to structure an organization and also many ways to model these structures. It would be presumptuous to think that all conceivable structures and models can be expressed with a fixed set of relations. For this reason, relations should be definded on a case-by-case basis.

Formally, relations are often seen as a set of tuples designating related objects (c.f. relational databases).

In our framework, we do not specify any specific representation for relations.

Application data

In many applications this entity will be the largest. The application data entity of an RDO should be seen as a container for application information that may originate from many sources. Any application may specify an arbitrary object that can be attached to the application data entity of a role. In this way flexibility is preserved while the basic role framework is kept small. This also emphasizes the distinction between roles and the use of roles in various applications. In particular, access control information associated with the role is stored in the application data entity.

Assignment of users to roles

Regardless of how roles are otherwise defined or used, we must always be able to assign users to roles. Outside the information system this amounts to determining which persons should be able to take on a certain role. In the information system a user can be a person, but also a program (agent) acting on the behalf of a person. To represent a user we use a persistent User Description Object within the system.

In an RDO, the users that are capable of assuming the role are listed in a Role User List.