The central notion of Role-Based Access Control (RBAC) is that users do not have discretionary access to enterprise objects. Instead, access permissions are administratively associated with roles, and users are administratively made members of appropriate roles. This idea greatly simplifies management of authorization while providing an opportunity for great flexibility in specifying and enforcing enterprise- specific protection policies. Users can be made members of roles as determined by their responsibilities and qualifications and can be easily reassigned from one role to another without modifying the underlying access structure. Roles can be granted new permissions as new applications and actions are incorporated, and permissions can be revoked from roles as needed.
Some users and vendors have recognized the potential benefits of RBAC without a precise definition of what RBAC constitutes. Some RBAC features have been implemented in commercial products without a frame of reference as to the functional makeup and virtues of RBAC [1]. This lack of definition makes it difficult for consumers to compare products and for vendors to get credit for the effectiveness of their products in addressing known security problems. To correct these deficiencies, a number of government sponsored research efforts are underway to define RBAC precisely in terms of its features and the benefits it affords. This research includes: surveys to better understand the security needs of commercial and government users [2], the development of a formal RBAC model, architecture, prototype, and demonstrations to validate its use and feasibility. As a result of these efforts, RBAC systems are now beginning to emerge. The purpose of this paper is to provide ad! ditional insight as to the motivations and functionality that might go behind the official RBAC name.
>From a functional perspective, RBAC's central notion is that of operations representing actions associated with roles and users that are appropriately made members of roles. The relationships between users, roles, and operations is depicted in Figure 1. As shown in Figure 1, the use of double arrows indicate a many-to-many relationship. For example, a single user can be associated with one or more roles, and a single role can have one or more user members. Roles can be created for various job positions in an organization. For example, a role can include Teller or Loan Officer in a bank, or Doctor, Nurse, or Clinician in a hospital. The operations that are associated with roles constrain members of the role to a specified set of actions. For example, within a hospital system the role of Doctor can include operations to perform diagnosis, prescribe medication, and order laboratory tests; the role of Researcher can be limited to gathering anonymous cl! inical information for studies; and the role of Social Worker may be to review patient profiles to flag possible suicidal patients or determine possible abuse cases.
Although RBAC does not promote any one protection policy, it has been shown to support several well-known security principles and policies that are important to commercial and government enterprises that process unclassified but sensitive information[2][8][9]. These include: the specification of competency to perform specific tasks; the enforcement of Least Privilege for administrators and general users; and the specification, as well as the enforcement, of conflicts of interest rules, which may entail duty assignment and dynamic and static separation of duties. These policies can be enforced at the time operations are authorized for a role, at the time users are authorized as members of a role, at the time of role activation (e.g., when a role is established as part of a user's active session), or when a user attempts to perform an operation on an object.
To demonstrate the importance of such policies, consider the unconstrained actions of Nicholas Leeson which lead to the bankruptcy of England's oldest investment firm in 1995. In particular, Leeson was allowed to run both the financial derivatives trading operation in Singapore as well as back- office functions where trades were settled. This is a mix of roles that can be - and in this case was - disastrous. In any firm serious about preventing fraud in its operations, this arrangement is flawed. Management at Barings PLC should never have had the same person making and settling trades. Such a conflict of interest policy can be specified centrally by management, administratively implemented, and enforced effectively using the RBAC framework.
In addition to RBAC's commercial relevance, RBAC has the potential to support policies that are essential within classified environments. Such policies can include one-directional information flow by the specification and enforcement of the Simple Security property and the Star-property[3][9]. [Note: The Simple Security Property states that a subject (i.e., a process executing on a user's behalf) must not be allowed to read from stroage repositories that are at a higher sensitivity level than the subject's current sensitivity level. The Star Property states that a subject must not be allowed to write to storage repositories that are at a lower sensitivity level than the subject's maximum sensitivity level allowed for reading].
One of RBAC's greatest virtues is the administrative capabilities it supports [3][5][9]. The administration of authorization data is widely acknowledged as an onerous process with a large and reoccurring expense. Under the RBAC framework, users are granted membership into roles based on their competencies and responsibilities. User membership into roles can be revoked easily and new memberships established as job assignments dictate. With RBAC, users are not granted permission to perform operations on an individual basis, but operations are associated with roles. Role association with new operations can be established as well as old operations deleted as organizational functions change and evolve. This basic concept has the advantage of simplifying the understanding and management of privileges: roles can be updated without having to update the privileges for every user on an individual basis.
Another administrative advantage of RBAC is that system administrators control access at a level of abstraction that is natural to the way enterprises typically conduct business. This is achieved by statically and dynamically regulating users' actions through the establishment and definition of roles, role hierarchies, relationships, and constraints. Thus, once an RBAC framework is established, the principal administrative actions are the granting and revoking of users into and out of roles. This is in contrast to the more conventional and less intuitive process of attempting to administer lower level access control mechanisms directly (e.g., access control lists (ACLs), capabilities, or type enforcement entities) on an object-by-object basis.
For distributed systems, another benefit is that RBAC administrator responsibilities can be divided among central and local protection domains, that is, central protection policies can be defined at an enterprise level while leaving protection issues that are of local concern at the organizational unit level. For example, within a distributed health care system, operations that are associated with health care providers may be centrally specified and pertain to all hospitals and clinics, but the granting and revoking of memberships into specific roles may be specified by administrators at local sites.
RBAC provides administrators with the capability to place constraints on role authorization, role activation, and operation execution. These constraints have a variety of forms. Constraints include cardinality and mutual exclusivity rules which can be applied on a role-by-role basis. In addition, constraints can be placed on the authorization of an operation to a role and on operations being performed on objects (i.e., time and location constraints).
The following subsections define RBAC entities and provide a precise definition for several representative constraints.
subject-user(s:subject) = the user associated with subject "s."
authorized-roles(s:subject) = {the roles associated with subject "s"}.
role-members(r:role) = {the users authorized for role "r"}.
user-authorized-roles(u:user) = {the roles associated with user "u"}.Note that the user associated with a subject is determined by a unique user identifier. Each subject is mapped to one individual user and possibly many roles. [Note: The user identifier is relevant for auditing, but witn an RBAC authorization scheme the role identifier(s) are what determine access.] RBAC also requires that if authorized-roles(s) = R and subject-user(s) = u, then "u" must be associated with the set of roles "R." This is better described as follows:
Assumption 1 (Consistent Subject) The consistent subject assumption is satisfied only if :
s:subject, u: user, R,r:roles:
subject-user(s) = u authorized-roles(s) = R)
u role-members(r) r R.
The type of operations and the objects that RBAC controls is dependent on the type of system in which it will be implemented. For example: within an operating system, operations might include read, write, and execute; within a database management system, operations might include insert, delete, append, and update; and within a transaction management system, operations would take the form of and exhibit all the properties of a transaction. The set of objects covered by the RBAC system include all of the objects accessible by the RBAC operations. However, not all file system and system objects need to be included in an RBAC scheme. For instance, access to infrastructure objects such as synchronization objects (e.g., semaphores, pipes, message segments) and temporary objects (e.g., temporary files and directories) may not necessarily be controlled within the RBAC protected object set.
An operation represents a unit of control that can be referenced by an individual role that is subject to regulatory constraints within the RBAC framework. It is important to note the difference between a simple mode of access and an operation. An operation can be used to capture security-relevant details or constraints that cannot be determined by a simple mode of access[2]. These details can be in terms of both method and granularity of access.
To demonstrate the importance of an RBAC operation, consider the differences between the access needs of a teller and an accounting supervisor in a bank. An enterprise defines a teller role as being able to perform a savings deposit operation. This requires read and write access to specific fields within a savings file. An enterprise may also define an accounting supervisor role that is allowed to perform correction operations. These operations require read and write access to the same fields of a savings file as the teller. However, the accounting supervisor may not be allowed to initiate deposits or withdrawals but only perform corrections after the fact. Likewise, the teller is not allowed to perform any corrections once the transaction has been completed. The difference between these two roles is the operations that are executed by the different roles and the values that are written to the transaction log file.
To demonstrate the importance of granularity of control, consider the need of a pharmacist to access a patient's record to check for interactions between medications and to add notes to the medication section of the patient record. Although such operations may be necessary, the pharmacist should not be able to read or alter other parts of the patient record.
As shown in Figure 3, operations are administratively associated with objects as well as with roles.
role-operations(r:roles) = {the operations that are associated with role "r"}.
operation-objects(op:operation) = {the authorized objects for which the operation "op" can be applied}.
Role hierarchies can be represented as ancestor relationships. The immediate parent relationship can be represented as an ordered pair ((Ri+1,Ri), >), where Ri+1 is the immediate parent and Ri the child and ">" is a relation "contains." Thus, Ri+1 > Ri, implies, Ri+1 contains Ri. As shown in Figure 2, the role Specialist is the immediate parent of the role Doctor, and the role Intern is an ancestor of the role Specialist (i.e., the role Specialist "contains" the role Intern). However, the role Cardiologist is not an ancestor of the role Rheumatologist. Because roles are contained by other roles through the "contains" relationship, granting membership in a role implies membership to all the roles that role "contains."
Rule 1 (Role Hierarchy) If a subject is authorized to access a role and that role contains another role, then the subject is also allowed to access the contained role:
s:subject, ri,j:roles :
rj authorized-roles(s) rj ri
ri authorized-roles(s).
The second property listed above is intended to preserve a policy of Static Separation of Duty or conflict of interest. This means that by virtue of a user being authorized as a member of one role, the user is not authorized as a member of a second role. For example, a user that is authorized to be a member of the role Teller in a bank may not be allowed to be a member of the role Auditor of the same bank. That is, the roles Teller and Auditor are mutually exclusive.
The policy of Static Separation of Duty can be centrally specified and can then be uniformly imposed on specific roles. The mutually exclusive roles for a given role and the Static Separation of Duty property can be specified as follows:
mutually-exclusive-authorization(r:roles) = {the list of roles that are mutually exclusive with role "r"}.Rule 2 (Static Separation of Duty) A user is authorized as a member of a role only if that role is not mutually exclusive with any of the other roles for which the user already possesses membership:
u:user, ri,j:roles : :
u role-members(ri) u role-members(rj) ri mutually-exclusive-authorization(rj)
The third property listed above which can be preserved under the granting of user membership to roles is the Cardinality property. Some roles can only be occupied by a certain number of employees at any given period of time. For example, consider the role of Manager. Although other employees may act in that role, only one employee may assume the responsibilities of a manager at any given time. A user can become a new member of a role as long as the number of members allowed for the role is not exceeded. The number of users allowed for a role and the existing number of users associated with a role is specified by the following two functions:
membership-limit (r: roles) = the membership limit ( 0) for role "r."
number-of-members(r:roles) = N ( 0) the number of existing members in role "r."Role capacity can now be described as:
Rule 3 (Cardinality) The capacity of a role cannot be exceeded by an additional role member:
r :roles :
membership-limit(r) number-of-members(r).
Role activation provides the context for which these organizational policies can be applied. As such, RBAC requires a user to first be authorized as being active in a role before a user can perform an action.
Depending on the organizational policy under consideration, checks are applied in terms of the role which is being proposed for activation, the operation which is being requested for execution, and/or the object which is being accessed. That is, a role can be activated if:
exec: (s: subject, op: operation) = {TRUE iff subject "s" can execute operation "op," otherwise it is FALSE}.
active-roles(s:subject) = {the current list of active roles for subject "s"}.The specification that a subject's proposed active role must be in the authorized role set for that subject is stated by the following property:
Rule 4 (Role Authorization) A subject can never have an active role that is not authorized for that subject:
s:subject, op: operation :
active-roles(s) authorized-role(s).
Once it is determined that a role is part of the authorized role set for the subject, the operation can be executed provided that the role is active. Even though a role may be in the role set, there may be certain organizational policies (such as dynamic separation of duty described below) that precludes the role from being activated. This provides the context from which other checks are made and is specified by the following rule:
Rule 5 (Role Execution) A subject can execute an operation only if the subject is acting within an active role:
s:subject, op: operation :
exec(s,op) active-roles(s) .
RBAC also provides administrators with the capability to enforce an organization-specific policy of Dynamic Separation of Duty. Static Separation of Duty provides an enterprise with the capability to address potential conflicts of interest issues at the time a user's membership is authorized for a role. However, in some organizations it is permissible for a user to be a member of two roles which do not constitute a conflict of interest when acted in independently, but introduce policy concerns when allowed to be acted in simultaneously.
For example, a static policy could require that no individual who has the role of Payment Initiator can also have the role of Payment Authorizer. Although such an approach may be adequate for some organizations, for others it may prove too rigid, making the cost of separation greater than the loss that might be expected. The objective behind Dynamic Separation of Duty is to allow more flexibility in operations. Dynamic Separation of Duty places constraints on the simultaneous activation of roles, so for example, an individual user can be authorized for both the roles Payment Initiator and Authorizer, but can dynamically assume only one of these roles at the same time.
The mutually exclusive roles for the proposed active role is specified by the following function:
mutually-exclusive-activation(r:roles) = {the list of active roles that are mutually exclusive with the proposed role "r"}.The RBAC Dynamic Separation of Duty rule is defined as:
Rule 6 (Dynamic Separation of Duty) A subject can become active in a new role only if the proposed role is not mutually exclusive with any of the roles in which the subject is currently active:
s:subject, r i,j:roles :i j :
ri active-roles(s) rj active-roles(s)
ri mutually-exclusive-activation(rj).
The specification that a subject can perform an operation only if the operation is authorized for the subject's proposed active role is provided by the following property:
Rule 7 (Operation Authorization) A subject can execute an operation only if the operation is authorized for the role in which the subject is currently active:
s:subject, op: operation r:roles :
exec(s,op) r active-roles(s)
op role-operations(r).
Operational Separation of Duty requires that for all the operations associated with a particular business function, no single user can be allowed to perform all of these operations. Therefore, the failure of one role to perform as expected can be detected by the organization. In RBAC terms, the Operational Separation of Duty policy can be enforced when roles are authorized for individual users and when operations are assigned to roles.
Operational Separation of Duty can be specified with the following function and property:
function-operations(f:function) = {the set of all operations required for a business function "f"}.
Rule 8 (Operational Separation of Duty) A role can be associated with an operation of a business function only if the role is an authorized role for the subject and the role had not been assigned previously to all of the other operations [Note: For this property, user-authorized-roles(u) is represented by ur(u).]:
s:subject, r:role, f:function :
(functi on-operations(f)
role-operations(r)).
access (s: subject, o: object) = {TRUE iff the subject can access the object, otherwise it is FALSE}.With the Role Authorization and Role Execution properties defined above (Rules 3 and 4), the Operation Access Authorization property defined below ensures that a subject's access an RBAC object can only be achieved through authorized operations by authorized active roles.
Rule 9 (Object Access Authorization) A subject can access an object only if the role is part of the subject's current active role set, the role is allowed to perform the operation, and the operation to access the object is authorized:
s:subject, o: object :
access(s,o) r: roles, op:operation :
r active-roles(s) op role-operations(r) o operation-objects(op).
Currently, the National Institute of Standards and Technology (NIST) is conducting research in the area of RBAC. To date three independently developed efforts on RBAC are underway at NIST: a Small Business Innovation Research (SBIR) program with Dr. Ravi Sandhu of George Mason University and Seta Corporation to help define RBAC and its feasibility, an effort with NSA's R23 Research and Engineering group and Dr. Virgil Gligor of the University of Maryland to create a formal model and implement RBAC on a policy-independent Mach microkernel-based operating system being developed by R23 called Synergy [6][10], and an Advanced Technology Program (ATP) effort being led by John Barkley of NIST to demonstrate how RBAC can be used for a health care system. Although these research efforts have shown great promise and has continued to generate enthusiasm within the research and vendor communities, RBAC remains a long way from reaching its full potential as a commercially viable technol! ogy. This could only be achieved through further research and consensus on the part of researchers, vendors, and the user community.
David F. Ferraiolo, Janet A. Cugini, D. Richard Kuhn National Institute of Standards and Technology U. S. Department of Commerce Gaithersburg MD 20899 11th Annual Computer Security Applications Proceedings 1995