Adelantos tecnológicos introducidos a la ciudad durante el siglo XIX y comienzos del

All RBAC models involve users, permissions, and roles. As well as these three basic components, mappings among them further make up the model.

The first component of the model, users, are defined to be human beings in the ANSI standard [6]. This differs from classical access control models where the entity trying to access objects is called a subject, and is considered to be a process acting on behalf of a user.

The second component of RBAC is the set of permissions. The simplest form of permission relates a single object over which it is possible to exercise access control with an operation or access mode which is valid on this object. There may be different operations for different objects; for example, for a printer object, the operation use is relevant, whereas for a file, read, write, create and delete would be valid operations. A permission can also be defined to contain a single object with multiple operations, or multiple objects with multiple operations. An example of the latter would be the execution of a complex method which involves multiple accesses to multiple objects.

Roles are, of course, the main focus of RBAC models. A role should have a unique name. Usually, a role is designed to correspond to a job function in a company, e.g. clerk, manager, programmer, etc. It is also customary for roles to be arranged in a role hierarchy [4] or role graph [7]. In the ANSI standard, the model called Core RBAC does not include role hierarchies.

As well as the three main components just described, RBAC models also consist of a number of mappings. The user assignment (UA) mapping maps users to roles, and is many to many; it defines the roles a user can perform. The permission assignment (PA) mapping maps permissions to roles and is also many-to-many. Role hierarchies are many to many mappings between roles. Role hierarchies are not allowed to have cycles so that each role offers a unique set of permissions to users assigned to it. The remaining mappings deal with the concept of sessions. Sessions model the run-time activation of roles by users. Whereas the mapping between sessions and roles is many to many, only one user is mapped to a session. The components of hierarchical RBAC from the ANSI standard are shown in Fig. 5.1, adapted from [6].

The final components of the ANSI model deal with separation of duty (also known as conflict of interest). Separation of duty (SOD) constraints identify sets of roles which should not be assigned to the same user, because this

5 Role-Based Access Control 57 assignment assignment Permission Permissions Operations Objects Role hierarchy roles session_ sessions user_ User Sessions Roles Users

Fig. 5.1.Components of the ANSI hierarchical RBAC

would allow that user to perpetrate some fraud against the organization. Static

separation of duty puts the constraint on the user-role assignment mapping. If

the set of roles in the constraint has cardinality 2, the intent of a static SOD constraint is that no user should ever be assigned to these two roles, i.e. that the UA mapping should never contain the assignment of these two roles to the same user. Dynamic SOD constraints allow the roles to appear in the UA mapping, but prevent roles which are in conflict from being simultaneously activated in a session.

As well as these basic components, the role graph model has a user-group hierarchy (called the group graph) [8] and a permission hierarchy. A group is defined as a set of users. Users can be regarded as a group of cardinality 1, so that in the group graph, only one entity type exists. Groups can be used to focus on the appropriate collections of users, just as roles allow de- signers to focus on appropriate collections of permissions. For example, one can create groups based on user attributes, such as certain qualifications, or to model things like committees. Assigning the users to the committee is a different design activity from assigning permissions to the role that describes the allowed activities of the committee. The assignment of users to groups can be performed by a line manager or human resources department, whereas the role design would be performed by more security-minded systems person- nel. Role design may be done before the system is deployed, whereas group memberships are more likely to change over time after the system is in use.

The hierarchy among permissions in the role graph model is used to model implications among permissions which arise because of object structure, or relationships among access modes. These ideas are based on some work for object-oriented databases [9, 10, 11]. When the object part of a permission is complex, like a deeply nested object or an XML document, implications based on the object structure can simplify the granting of permissions. For example, the permission to read an XML document can imply the permission to read all the subelements of that document, to an arbitrary number of levels. Having to specify the individual element-level permissions can be avoided if

58 S.L. Osborn

the system automatically deduces them from the document-level permission by implications based on object structure. The access modes may also have implications; for example, the ability to update an object may imply the ability to read it. Clearly these implications vary from one application to the next. Having automatic implications based on the relationships among access modes can also simplify the design of the security model. The components of the role graph model are shown in Fig. 5.2.

Group graph

Bob

Role graph Privileges

MaxRole Bookkeepers Accounting VP1 VP2 Base Clerk Engineers

Lisa Joe Sue

Engineer Writer ProjectBase MinRole Privilege-role assignments User/group-role assignments

Fig. 5.2.Components of the role graph model

5.3 Contrasts Between the Role Graph and ANSI