See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220855076

NIST model for role-based access control: Towards a unified standard

Conference Paper · January 2000

Source: DBLP

CITATIONS READS
588 296

3 authors:

Ravi Sandhu David Ferraiolo

University of Texas at San Antonio National Institute of Standards and Technology
274 PUBLICATIONS 17,508 CITATIONS 35 PUBLICATIONS 6,707 CITATIONS

SEE PROFILE SEE PROFILE

D. Richard Kuhn
National Institute of Standards and Technology
164 PUBLICATIONS 9,680 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Security Vulnerability Trends View project

Access Control Models and Enforcements in Cloud and Internet of Things View project

All content following this page was uploaded by David Ferraiolo on 11 September 2014.

The user has requested enhancement of the downloaded file.

 The NIST Model for Role-Based Access Control:
Towards A Unied Standard
y y
Ravi Sandhu, David Ferraiolo and Richard Kuhn

Abstract 1 INTRODUCTION
This paper describes a unied model for role-based
access control (RBAC). RBAC is a proven technology The paper proposes a standard reference model for
for large-scale authorization. However, lack of a role-based access control (RBAC). RBAC is a tech-
standard model results in uncertainty and confusion nology that is both new and old. Although rigorous
about its utility and meaning. The NIST model RBAC models have only recently appeared, the ba-
seeks to resolve this situation by unifying ideas from sic concept of roles has been used for decades as
prior RBAC models, commercial products and research a means of managing privileges. The lack of stan-
prototypes. It is intended to serve as a foundation dards for RBAC has led to roles being implemented
for developing future standards. RBAC is a rich in dierent ways, impeding the advance of RBAC
and open-ended technology which is evolving as users, technology. The term RBAC itself does not have a
researchers and vendors gain experience with it. The
NIST model focuses on those aspects of RBAC for which generally accepted meaning, and is used in dierent
consensus is available. It is organized into four levels ways by dierent vendors and users. The goal of
of increasing functional capabilities called at RBAC, this paper is to provide a standard in this arena.
hierarchical RBAC, constrained RBAC and symmetric RBAC provides a valuable level of abstraction
RBAC. These levels are cumulative and each adds to promote security administration at a business
exactly one new requirement. An alternate approach enterprise level rather than at the user identity
comprising at and hierarchical RBAC in an ordered level. The basic role concept is simple: establish
sequence and two unordered features|constraints and permissions based on the functional roles in the
symmetry|is also presented. The paper furthermore
identies important attributes of RBAC not included enterprise, and then appropriately assign users to
in the NIST model. Some are not suitable for inclusion a role or set of roles. With RBAC, access decisions
in a consensus document. Others require further work are based on the roles individual users have as
and agreement before standardization is feasible. part of an enterprise. Roles could represent the
tasks, responsibilities, and quali cations associated
Laboratory for Information Security Technology (LIST), with an enterprise. Because the roles within an
George Mason Univ., [email protected], www.list.gmu.edu. enterprise are relatively persistent with respect
The work of Ravi Sandhu is partially supported by NIST
and by NSF. to user turnover and task re-assignment, RBAC
y Information Technology Lab., National Institute of provides a powerful mechanism for reducing the
Standards and Technology (NIST), [email protected], complexity, cost and potential for error in assigning
[email protected], www.itl.nist.gov
user permissions within the enterprise. Because
roles within an enterprise typically have overlapping
permissions, RBAC models often include features
to establish role hierarchies, where a given role can
include all permissions of another role.
RBAC allows for speci cation and enforcement of
a variety of protection policies which can be tailored
on an enterprise-by-enterprise basis. The policies
enforced within a particular system are the result of Flat RBAC
the con guration of various components of RBAC.
This approach to access control and authorization Hierarchical RBAC
management is a dramatic departure from existing Constrained RBAC
access control standards|such as classical discre-
tionary and mandatory access control|where pol- Symmetric RBAC
icy is essentially \hard-wired" into the access con- The rest of this paper is organized as follows.
trol model.1 Because permissions are organized into Section 2 gives an overview of the NIST RBAC
enterprise functions through roles, con ict of inter- model and its four levels. Sections 3 through 6
est relationships are more evident than if dealing describe each of the four levels in sequence, along
with permissions on an individual basis. As such, with rationale for the features packaged in each
many RBAC models support the establishment of level. The NIST model focuses on those aspects of
separation of duty constraints among roles. This RBAC for which consensus is available. Section 7
provides administrators with enhanced capabilities discusses important attributes of RBAC that are
to specify and enforce enterprise policy as compared not included in the NIST model. Some of these are
to existing access control standards. not suitable for inclusion in a consensus document.
Because of customer demand for RBAC, ven- Others require further work and agreement in
dors have incorporated RBAC features into their the RBAC community before their inclusion is
database, system management, and operating sys- warranted. Section 8 concludes the document.
tem products. These development eorts continue
without any general agreement as to what actu- 2 MODEL OVERVIEW
ally constitutes RBAC features. As an attempt
at rigorously de ning RBAC features, a number This section provides an overview of the NIST
of RBAC models have been proposed and im- RBAC model as summarized in table 1. A rationale
plemented FK92, FCK95, FBK99, Gui95, NO99, for each of the four levels of the model is also
RS98, SCFY96, San98b, San98a, TDH92]. These given. Readers familiar with RBAC concepts and
models have been independently proposed without terminology should be able to understand the model
any attempt at standardizing salient RBAC fea- largely by reading this section. Readers relatively
tures. As such, RBAC remains an amorphous con- new to RBAC can skim this section and revisit it
cept. One means to further the development and after reading the description of the four levels of the
use of RBAC technology is to develop standards. model in the following sections.
The NIST RBAC model is a rst step in this direc- The NIST RBAC model is organized in a four
tion. step sequence of increasing functional capabilities
RBAC is a rich and open-ended concept which given below. These levels are cumulative in that
ranges from very simple at one extreme to fairly each includes the requirements of the previous ones
complex and sophisticated at the other. It has been in the sequence. Each level adds exactly one new
recognized that a single de nitive model for RBAC requirement. Rationale for specifying this sequence,
is therefore unrealistic. Such a model would either and for the choice of added features at each level, is
include or exclude too much, and would represent given below as each level is described. Additional
one point along a spectrum of choices. The NIST rationale is given in subsequent sections that discuss
RBAC model is consequently organized in a four each level in turn.
step sequence of increasing functional capabilities
given below. These levels are cumulative in that 2.1 Flat RBAC
each includes the requirements of the previous ones Flat RBAC embodies the essential aspects of RBAC.
in the sequence.2 The basic concept of RBAC is that users are as-
1 A convincing testimony to the exibility of RBAC is RBAC features as independent unordered requirements. At
its ability to enforce mandatory and discretionary access this point we feel that the alternate approach is preferable
controls OSM00]. because it doe not force an ordering amongst features that
2 An alternate approach is presented in Appendix A. This can be independently implemented. We have refrained from
alternative recognizes Flat RBAC and Hierarchical RBAC as changing the main body of the paper since it has previously
an ordered sequence but treats Constrained and Symmetric been circulated for comments.
signed to roles, permissions are assigned to roles Role hierarchies can be inheritance hierarchies
and users acquire permissions by being members of (whereby activation of a role implies activation of
roles. The NIST RBAC model requires that user- all junior roles) or activation hierarchies (whereby
role and permission-role assignment can be many- there is no such implication) or both. The precise
to-many. Thus the same user can be assigned to nature of a role hierarchy is left open.
many roles and a single role can have many users. Rationale. Role hierarchies in the form of ar-
Similarly, for permissions. Flat RBAC has a re- bitrary partial orders are the single most desirable
quirement for user-role review whereby the roles feature in addition to at RBAC. This feature has
assigned to a speci c user can be determined as often been mentioned in the literature and is avail-
well as users assigned to a speci c role. (A similar able in a number of existing products. Justi ca-
requirement for permission-role review is imposed tion for requiring the transitive, re exive and anti-
in symmetric RBAC.) Finally, at RBAC requires symmetric properties of a partial order have been
that users can simultaneously exercise permissions amply discussed in the literature SCFY96]. There
of multiple roles. This precludes products that re- is strong consensus on this aspect. There is also
strict users to activation of only one role at a time. strong consensus regarding the bene ts of support-
Rationale. Flat RBAC captures the features ing arbitrary partial orders. Nevertheless there are
of traditional group-based access control as imple- products which support only restricted hierarchies,
mented in operating systems through the current which provide substantially improved capabilities
generation. As such it is a widely deployed and beyond the at model. Hence, the recognition of
familiar technology. The features required of at two sub-levels in this context.
RBAC are obligatory for any form of RBAC and
are almost obvious. The main issue in de ning at 2.3 Constrained RBAC
RBAC is to determine which features to exclude. Constrained RBAC adds a requirement for enforc-
The NIST RBAC model has deliberately kept a very ing separation of duties (SOD). SOD is a time-
minimal set of features in at RBAC. In particu- honored technique for reducing the possibility of
lar, these features accommodate traditional but ro- fraud and accidental damage, known and prac-
bust group-based access control. Not every group- ticed long before the existence of computers. SOD
based mechanism quali es because of the require- spreads responsibility and authority for an action
ments given above. or task over multiple users, thereby raising the risk
involved in committing a fraudulent act by requir-
2.2 Hierarchical RBAC ing the involvement of more than one individual.
Hierarchical RBAC adds a requirement for support- Many dierent SOD requirements have been iden-
ing role hierarchies. A hierarchy is mathematically ti ed in the literature. These include static SOD
a partial order de ning a seniority relation between (based on user-role assignment) and dynamic SOD
roles, whereby senior roles acquire the permissions (based on role activation). The exact form of SOD
of their juniors. The NIST model recognizes two that is supported is left open by the NIST RBAC
sub-levels in this respect. model.
Rationale. SOD is often mentioned as one of
General Hierarchical RBAC the driving motivations of RBAC. It is practiced
In this case there is support for an arbitrary routinely in organizations and should be supported
partial order to serve as the role hierarchy. by sophisticated access control products. It is
introduced after hierarchies principally because
Restricted Hierarchical RBAC existing products more often support hierarchies
Some systems may impose restrictions on the than SOD.
role hierarchy. Most commonly, hierarchies are 2.4 Symmetric RBAC
limited to simple structures such as trees or
inverted trees. Symmetric RBAC adds a requirement for permission-
role review similar to user-role review introduced in
These sub-levels also apply to subsequent forms of level 1. Thus the roles to which a particular per-
RBAC as indicated in table 1. mission is assigned can be determined as well as
 Level Name RBAC Functional Capabilities
1 Flat users acquire permissions through roles
RBAC must support many-to-many user-role assignment
(see Figure 1) must support many-to-many permission-role assignment
must support user-role assignment review
users can use permissions of multiple roles simultaneously
2 Hierarchical Flat RBAC +
RBAC must support role hierarchy (partial order)
(see Figure 2) level 2a requires support for arbitrary hierarchies
level 2b denotes support for limited hierarchies
3 Constrained Hierarchical RBAC +
RBAC must enforce separation of duties (SOD)
(see Figures 6 and 7) level 3a requires support for arbitrary hierarchies
level 3b denotes support for limited hierarchies
4 Symmetric Constrained RBAC +
RBAC must support permission-role review with performance
(see Figures 9 and 10) eectively comparable to user-role review
level 4a requires support for arbitrary hierarchies
level 4b denotes support for limited hierarchies
Table 1: RBAC Variations Organized as Levels

permissions assigned to a speci c role. The perfor-

mance of permission-role review must be eectively
UA PA

comparable to that of user-role review. USER

ASSIGNMENT
PERMISSION
P

Rationale. The requirement for permission-role

U R ASSIGNMENT
PERMISS-
USERS ROLES
review has been deferred until level 4 because it can
IONS

be intrinsically dicult to implement in large-scale

distributed systems. It is sometimes mentioned Figure 1: Flat RBAC
as an intrinsic aspect of RBAC that distinguishes
RBAC from group-based access control. The NIST
model takes a pragmatic approach in this regard
so this feature that is hard to implement in certain widely deployed and familiar technology that serves
environments is reserved for higher levels of RBAC. well as the starting point for RBAC. This approach
bypasses the usual fruitless debate about the dier-
3 FLAT RBAC ence between roles and groups San97] by recogniz-
ing the underlying commonality. At the same time
Flat RBAC is illustrated in gure 1. The features by allowing additional more sophisticated levels of
required of at RBAC are obligatory for any form of RBAC, the NIST model recognizes that RBAC is
RBAC and are almost obvious. The main issue with more than just another name for traditional but ro-
at RBAC is the features that have been excluded. bust group-based access controls.
Flat RBAC captures the features of traditional An important aspect of at RBAC is the ability
group-based access control as implemented in op- to support many-to-many user assignment relation.
erating systems through the current generation. Clearly every practical system will have some limit
Some might argue that these features are not su- on the number of roles to which a user can belong.
cient to merit the designation of RBAC. The NIST At the same time products should have some
RBAC model recognizes traditional group-based ac- scalability in this respect. Some current systems
cess control as the rst level of RBAC because it is impose a very small limit, such as 16 or 32, on
the number of roles a user be assigned to. Others choice to activate and deactivate roles in a given
allow larger numbers in the 100's and even 1000's. session at the user's discretion. This enables the
The NIST model does not legislate a quantitative user to activate sessions with roles appropriate to
minimum that must be supported in order to satisfy the task that the user is pursuing. In particular
the at requirement. An operational model would powerful roles can be kept dormant until they are
need to specify numerical requirements in this needed to provide an element of least privilege
regard. There are other aspects of RBAC where and safety. Some systems limit users to activation
similar scalability issues arise. Scalability is further of only a single role in a session. The NIST
discussed in section 7. model does not require support for sessions with
The requirement that users acquire permissions discretionary role activation. It does require the
through roles is the essence of RBAC. Flat RBAC ability to activate multiple roles simultaneously and
does not exclude other means by which users can in a single session. This precludes products that
acquire permissions such as by direct assignment to limit users to activation of a single role in a session.
the user or by means of security labels in lattice- This feature is considered overly restrictive.
based access control San93]. Flat RBAC requires support for user-role review
Figure 1 shows three sets of entities called users whereby it can be eciently determined which
(U), roles (R), and permissions (P). A user in this roles a given user belongs to and which users a
model is a human being or other autonomous agent given role is assigned to. It is often felt that a
such as a process or a computer. A role is a job similar requirement for permission-role review is
function or job title within the organization with an intrinsic part of RBAC. Permission-role review
some associated semantics regarding the authority enables ecient answers to questions about which
and responsibility conferred on a member of the permissions are assigned to a role and which roles
role. A permission is an approval of a particular a permission is assigned to. Some have argued that
mode of access to one or more objects in the support for permission-role review is the essential
system. The terms authorization, access right and feature that distinguishes roles from groups San97].
privilege are also used in the literature to denote In the NIST model requirement for permission-role
a permission. Permissions are always positive and review is deferred until level 4 in recognition of its
confer the ability to the holder of the permission intrinsic diculty in large-scale distributed systems.
to perform some action(s) in the system.3 The The at RBAC model leaves open many impor-
nature of a permission depends greatly on the tant issues of RBAC that must be addressed in an
implementation details of a system and the kind of implementation. There are no scalability require-
system that it is. A general model for access control ments on the numbers of roles, users, permissions,
must therefore treat permissions as uninterpreted etc., that should supported. The nature of permis-
symbols to some extent. The exact nature of sions and support for discretionary role activation is
permissions in a system is left open by at RBAC. not fully speci ed. The behavior of revocation is not
Flat RBAC requires that user-role assignment speci ed. Revocation can occur when a user is re-
(UA) and permission-role assignment (PA) are moved from a role or a permission is removed from
many-to-many relations. This is an essential aspect a role. How quickly the revocation actually takes
of RBAC. The concept of a session is not explicitly place, particularly with respect to activity which is
a part of at RBAC. A session corresponds to a already under way, is left unspeci ed. In some ways
particular occasion when a user signs on to the this is an assurance issue. The important issue of
system to carry out some activity. The semantics role administration is not speci ed. Role adminis-
of a session vary widely from system to system. tration is concerned with who gets to assign users
In some cases all roles of a user (as assigned in to roles and permissions to roles. There are two
the UA relation) are activated in every session reasons why these features are not speci ed in at
of the user. In other cases the user is given a RBAC. In some cases it is not appropriate to leg-
3 Flat RBAC does not rule out the use of so-called negative
islate the details of a particular feature in a stan-
permissions which deny access. In general, the NIST model dard model. Since many choices are available it is
prescribes features required at a particular level of RBAC, upto vendors and the market to determine which
but vendors are free to include additional features as they combinations turn out to be most useful. In other
see t.
 commonly, hierarchies are limited to simple
structures such as trees or inverted trees.
ROLE
RH
HIERARCHY
UA PA

USER
ASSIGNMENT
PERMISSION
P
4.1 Limited vs. General Hierarchies
Figure 3(a) shows an inverted tree hierarchy that
U R ASSIGNMENT
PERMISS-

might exist in a hypothetical engineering depart-

USERS ROLES IONS

ment. In these diagrams senior roles are shown to-

Figure 2: Hierarchical RBAC wards the top with edges connecting them to junior
roles. Transitive edges, such as from PE1 to ED
are omitted to avoid clutter. There is a junior-most
role ED to which all employees in the department
cases there is insucient consensus in the commu- belong. Senior to this role are roles for two projects
nity to justify making a speci c choice as part of within the department, project 1 on the left and
a standard. These issues are further discussed in project 2 on the right. Each project has an engi-
section 7. neer role and, senior to it, production and quality
engineer roles. An inverted tree facilitates sharing
4 HIERARCHICAL RBAC of resources. Resources made available to the ED
role are also available to senior roles. However, an
Hierarchical RBAC is illustrated in gure 2. It inverted tree does not allow aggregation of resources
diers from gure 1 only in introduction of the from more than one role.
role hierarchy relation RH. Role hierarchies are
often included whenever roles are discussed. They Figure 3(b) shows a tree hierarchy in which senior
are also commonly implemented in systems that roles aggregate the permissions of junior roles. Thus
provide roles. PL1 acquires the permissions of PE1 and QE1,
and may have additional permissions of its own.
Role hierarchies are a natural means for structur- Trees are good for aggregation but do not support
ing roles to re ect an organization's lines of author- sharing. In this hierarchy there can be no sharing
ity and responsibility. Examples of role hierarchies of resources between the project 1 roles on the left
are shown in gure 3. Mathematically, these hierar- and project 2 roles on the right.
chies are partial orders. A partial order is a re ex-
ive, transitive and anti-symmetric relation. By con- Figure 3(c) shows a general hierarchy that facil-
vention more powerful (or senior) roles are shown itates both sharing and aggregation. Within the
toward the top of role-hierarchy diagrams, and less engineering department there is a junior-most role
powerful (or junior) roles toward the bottom. Jus- ED and senior-most role DIR. In between there are
ti cation for requiring the transitive, re exive and roles for two projects. Each project has a senior-
anti-symmetric properties of a partial order have most project lead role (PL1 and PL2) and a junior-
been amply discussed in the literature SCFY96]. most engineer role (E1 and E2). In between each
There is strong consensus on this aspect. There is project has two incomparable roles, production en-
also strong consensus regarding the bene ts of sup- gineer (PE1 and PE2) and quality engineer (QE1
porting arbitrary partial orders. Nevertheless there and QE2). This structure can, of course, be ex-
are products which support only limited hierarchies, tended to dozens and even hundreds of projects
but nevertheless provide substantially improved ca- within the engineering department. Moreover, each
pabilities beyond a at model. Hence, the recogni- project could have a dierent structure for its roles.
tion of two sub-levels in this context as follows. The example can also be extended to multiple de-
partments with dierent structure and policies ap-
General Hierarchical RBAC plied to each department. Practical hierarchies will
In this case there is support for an arbitrary typically have an irregular structure rather than the
partial order to serve as the role hierarchy. highly symmetrical construction of this example.
We emphasize there is no requirement that there
Limited Hierarchical RBAC be a seniormost role such as DIR in this example.
If any restriction is imposed on the structure of Similarly, there is no requirement that there be
the role hierarchy then we are in this case. Most a juniormost role such as ED. For example, the
Production Quality Production Quality Project lead 1 (PL1) Project lead 2 (PL2)
Engineer 1 Engineer 1 Engineer 2 Engineer 2
(PE1) (QE1) (PE2) (QE2) Production Quality Production Quality
Engineer 1 Engineer 1 Engineer 2 Engineer 2
Engineer 1 (E1) Engineer 2 (E2) (PE1) (QE1) (PE2) (QE2)

Engineer 1 (E1) Engineer 2 (E2)

Engineering Department (ED)

Engineering Department (ED)

(a) A Inverted Tree Hierarchy

(a) No Seniormost Role

Director (DIR)
Director (DIR)

Project lead 1 (PL1) Project lead 2 (PL2)

Project lead 1 (PL1) Project lead 2 (PL2)
Production Quality Production Quality
Engineer 1 Engineer 1 Engineer 2 Engineer 2 Production Quality Production Quality
(PE1) (QE1) (PE2) (QE2) Engineer 1 Engineer 1 Engineer 2 Engineer 2
(PE1) (QE1) (PE2) (QE2)

(b) A Tree Hierarchy Engineer 1 (E1) Engineer 2 (E2)

Director (DIR) (b) No Juniormost Role

Project lead 1 (PL1) Project lead 2 (PL2)

Project lead 1 (PL1) Project lead 2 (PL2)
Production Quality Production Quality
Production Quality Production Quality Engineer 1 Engineer 1 Engineer 2 Engineer 2
Engineer 1 Engineer 1 Engineer 2 Engineer 2 (PE1) (QE1) (PE2) (QE2)
(PE1) (QE1) (PE2) (QE2)
Engineer 1 (E1) Engineer 2 (E2)
Engineer 1 (E1) Engineer 2 (E2)

(c) No Seniormost or Juniormost Role

Engineering Department (ED)

(c) A General Hierarchy

Figure 4: Example Role Hierarchies Without Se-
niormost or Juniormost Roles
Figure 3: Example Role Hierarchies
of the Test Engineer' role that need to be inherited
upwards. Roles such as Test Engineer' are called
hierarchies of gure 4 are all acceptable. The design private roles SCFY96]. A similar situation holds
of a suitable hierarchy is a matter of policy. The with respect to Programmer' role.
requirement is to support general hierarchies in level
2a and limited ones in level 2b. 4.3 Inheritance vs. Activation
Hierarchies
4.2 Limited Inheritance There are two distinct interpretations of a role
Senior roles such as DIR in gure 3(c) are often hierarchy that have been discussed in the liter-
considered dangerous because they aggregate too ature. In one interpretation members of a se-
much power. Even if users in these roles are very nior role in the hierarchy are regarded as inher-
trustworthy they have the potential to make major iting permissions from juniors. This is called the
mistakes as well as being susceptible to malicious permission-inheritance interpretation and the hier-
software. It is possible to limit inheritance in role archy is called an inheritance hierarchy. Interpret-
hierarchies as illustrated in gure 5. Figure 5(a) ing gure 3(c) as a inheritance hierarchy, when role
shows that the Project Supervisor role inherits all PL1 is activated the permissions assigned to PL1,
permissions of the project. Figure 5(b) on the other PE1, QE1, E1, ED and E are all available for use.
hand allows Test Engineers to have permissions in In the alternate interpretation, activation of a se-
the Test Engineer' role that are not inherited by nior role does not automatically activate permis-
Project Supervisor. Test engineers are assigned to sions of junior roles. This is called the activation
the Test Engineer' role whereas the Test Engineer interpretation and the hierarchy is called an activa-
role is simply a placeholder for those permissions tion hierarchy. In this case activation of role PL1
does not activate permissions of the junior roles.
Each junior role must be explicitly activated to en- Project Supervisor Test Engineer’ Project Supervisor Programmer’

able its permissions in a session. It is possible to

have both interpretations simultaneously applied. Test Engineer Programmer Test Engineer Programmer

In such cases the activation hierarchy may extend

the inheritance hierarchy or be separate and inde- Project Member Project Member

pendent of it San98a]. The NIST model leaves open

the exact meaning of role hierarchies since multiple
(a) (b)

interpretations are possible. Figure 5: Example of Limited Inheritance

5 CONSTRAINED RBAC 5.1 Static Separation of Duty

Constrained RBAC, shown in Figures 6 and 7, Con ict of interest in a role based system may
adds constraints to the hierarchical RBAC model. arise as a result of a user gaining authorization for
Constraints may be associated with the user-role permissions associated with con icting roles. One
assignment (static, Figure 6), or with the activation means of preventing this form of con ict of interest
of roles within user sessions (dynamic, Figure 7). is through static separation of duty (SSD), that is,
Separation requirements are used to enforce con ict to enforce constraints on the assignment of users to
of interest policies that organizations may employ roles. This means that if a user is authorized as
to prevent users from exceeding a reasonable level a member of one role, the user is prohibited from
of authority for their positions. being a member of a second role. For example, a
Separation of duty refers to the partitioning user who is authorized for the role Billing Clerk may
of tasks and associated privileges among dierent not be authorized for the role Accounts Receivable
roles so as to prevent a single user from garnering (AR) Clerk (see Figure 8). That is, the roles Billing
too much authority. The motivation is to ensure Clerk and Accounts Receivable Clerk are mutually
that fraud and major errors cannot occur without exclusive. The SSD policy can be centrally speci ed
deliberate collusion of multiple users to this end. and then be uniformly imposed on speci c roles.
Within an RBAC system separation concepts are Constraints are inherited within a role hierarchy.
supported by the principle of least privilege. For example, if the role Accounts Receivable Su-
Least privilege is the time honored administrative pervisor inherits Accounts Receivable Clerk, and
practice of selectively assigning privileges to users Accounts Receivable Clerk has an SSD relationship
such that the user is given no more privilege with Billing Clerk, then Accounts Receivable Su-
than is necessary to perform his/her job function. pervisor also has an SSD relationship with Billing
The principle of least privilege avoids the problem Clerk. Another way of thinking about this is that
of an individual having the ability to perform any instance of AR Supervisor can be treated as
unnecessary and potentially harmful actions merely an instance of Accounts Receivable Clerk. There-
as a side eect of granting the ability to perform fore, the SSD constraint that Billing Clerk has with
desired functions. Permissions (or privileges) are Accounts Receivable Clerk must also apply to AR
rights granted to an individual, or subject acting Supervisor.
on behalf of a user, that enable the holder of those Because a containing role is eectively an in-
rights to act in the system within the bounds of stance of its contained roles, no SSD relationship
those rights. Least privilege provides a rationale for can exist between them. In the previous example,
where to install the separation boundaries that are it would not make sense to have an SSD relation-
to be provided by RBAC protection mechanisms. ship between AR Supervisor and AR Clerk, since by
The NIST model allows for both static and de nition there cannot be any con ict of interest.
dynamic separation of duty, but leaves open which Otherwise, a containment relationship should not
of these should be supported and exactly in what have been used to inherit implicit properties that
form. con ict with explicit properties being de ned.
 SOD CONSTRAINTS
ROLE
Acct. Recv. Billing Cashier
RH
HIERARCHY Supervisor Supervisor Supervisor
UA PA

USER PERMISSION
U ASSIGNMENT R P
ASSIGNMENT
PERMISS-
USERS ROLES IONS

Accts. Recv. Billing Cashier

Clerk Clerk
Figure 6: Constrained RBAC|Static SOD

Accounts
SOD CONSTRAINTS
ROLE Receivable
RH
HIERARCHY
UA PA

USER PERMISSION
U ASSIGNMENT R P
ASSIGNMENT
PERMISS- Accounting
USERS S ROLES IONS
SESSIONS

.
.
Static SOD Inheritance
user . roles

Figure 8: Constrained RBAC|SOD Example

Figure 7: Constrained RBAC|Dynamic SOD
tion will not arise. Although this eect could be
achieved through the establishment of an SSD re-
5.2 Dynamic Separation of Duty lationship, DSD relationships generally provide the
enterprise with greater operational exibility.
RBAC also provides administrators with the capa- Note that unlike roles in an SSD relation, roles
bility to enforce an organization speci c policy of in a DSD relation can be hierarchically related
dynamic separation of duty (DSD). SSD provides through the containment relation. This is consis-
an organization with the capability to address po- tent with the DSD property of restricting simulta-
tential con ict-of-interest issues at the time a user's neous activation of roles and that of a role hierarchy
membership is authorized for a role. With DSD it is as a representation of a user's implicit and explicit
permissible for a user to be authorized as a member authorizations for a role. As such, authorization
of a set of roles which do not constitute a con ict of and activation can be treated as independent no-
interest when acted in independently, but produce tions.
policy concerns when allowed to be acted in simul-
taneously. For example, a user may be authorized Some aspects of separation of duty can be im-
for both the roles of Cashier and Cashier Supervi- plemented with at RBAC or simple group-based
sor, where the supervisor is allowed to acknowledge mechanisms. The NIST model requires role hierar-
corrections to a Cashier's open cash drawer. If the chies as a prerequisite in systems providing separa-
individual acting in the role Cashier attempted to tion of duty because most of the bene ts of RBAC
switch to the role Cashier Supervisor, RBAC would are tightly integrated with the provision of hierar-
require the user to drop his or her Cashier role, and chies. Separation of duty mechanisms implemented
thereby force the closure of the cash drawer before without hierarchies have serious limitations on ex-
assuming the role Cashier Supervisor. As long as ibility and functionality.
the same user is not allowed to assume both of these Many researchers have proposed separation of
roles at the same time, a con ict of interest situa- duty policies for RBAC AS99, CW87, FBK99,
 to roles regardless of where they might reside within
SOD CONSTRAINTS the organization. When maintaining permission as-
signments, special attention is taken to abide by the
ROLE
RH
HIERARCHY
UA PA
principle of least privilege. The challenge then be-
USER PERMISSION comes how to maintain appropriate permission as-
U ASSIGNMENT R ASSIGNMENT
P
PERMISS- signments, among the aggregate of system objects,
USERS ROLES IONS
that correspond to the user's authorized functions
or duties within the enterprise.
Figure 9: Symmetric RBAC|Static SOD The need to review permission assignments can
arise due to a variety of administrative situations.
When a user departs from the enterprise, changes
jobs or responsibilities within the enterprise, or ex-
isting permissions become obsolete great care must
be applied in reviewing and selectively deleting per-
missions that are no longer necessary for the op-
erations of the enterprise. In the case where the
SOD CONSTRAINTS
ROLE
RH

user departs from the enterprise all of the user's

HIERARCHY
UA

permissions need to be eectively revoked. One ap-

PA

proach to this problem might be to simply delete

USER PERMISSION
U ASSIGNMENT R ASSIGNMENT P

USERS S ROLES
PERMISS-
all of the user's existing accounts within the en-
terprise. However, this would leave garbage in the
IONS
SESSIONS

system, that might lead to potentially damaging ac-

. cesses. In the case where the employee changes re-
sponsibilities within the enterprise, the administra-
.
user . roles

tor must take great care in selectively revoking per-

missions. Deleting permissions that are necessary
Figure 10: Symmetric RBAC|Dynamic SOD for the performance of the user's new responsibil-
ities would inhibit the user's ability to eectively
perform his/her job. Not deleting permissions that
are no longer necessary in performing the user's new
GGF98, Kuh97, NO99, NP90, San88, SZ97]. The responsibilities would be a violation of the principle
separation of duty features discussed here are most of least privilege, and thereby provide the potential
closely related to those proposed by Ferraiolo et for abuse.
al FCK95]. Starting at Level 1 RBAC systems are required to
establish and maintain many-to-many relationships
6 SYMMETRIC RBAC among user-role and permission-role assignments.
Among these relations level 1 and level 2 RBAC
Maintaining appropriate and accurate permission- systems require an interface for the review of user-
role assignments is an essential component of any role assignments. Level 1 requirements include the
authorization management scheme. Permission-role establishment of the set of roles that are directly
assignments of the past may become inappropriate assigned to a user. Level 2 RBAC extends coverage
as situations change within an enterprise and may of user-role review to include not only the roles that
become detrimental to the policy objectives of an are assigned to a user but also the roles that are
organization. Maintaining these relations can be inherited by the roles that are assigned to the user.
especially problematic in situations where user and
role permissions are established over distributed ad- Level 4 RBAC further extends these requirements
ministrative boundaries where the coordinated ef- to include an interface for permission-role review
forts of multiple administrators become a necessity. with respect to a de ned user or role. These
requirements pertain to the type of data that is
To eectively maintain permission assignments returned to the administrator as a result of a review,
an organization must be provided with the ability the ability to select direct or indirect permission
to identify and review the assignment of permissions
assignments, and for distributed systems the ability hierarchy, limits on user-role assignments, etcetera.
to select the target systems in which the permission A given product may be scalable in some dimensions
review will be applied. but not in others.
Level 4 or symmetric RBAC requires that the As a general guideline we might adopt scale
permission-role review interface provide the capa- measure as follows.
bility to return any one of two types of results.
These results include the complete set of objects Small scale: 10's
that are associated with the permissions assigned
to a particular user or role, or the complete set of Medium scale: 100's
operation and object pairs that are associated with Large scale: 1000's
the permissions that are assigned to a particular
user or role. As an option on this query symmetric However, a product can be small scale in, say,
RBAC requirements further include the ability to number of roles and large scale in number of users.
selectively de ne direct and indirect permission as-
signment. Direct permission assignment pertains to The NIST RBAC model does not incorporate a
the set of permissions that are assigned to the user scalability attribute but this is an important issue
and/or to the role(s) for which the user is assigned. in choosing a product.
Indirect permission assignments pertain to the set
of permissions that are included in the direct per- 7.2 Authentication
mission assignment in addition to the permissions The NIST RBAC model does not address the
that are assigned to the roles that are inherited by issue of authentication. How are individual users
the roles assigned to the user. As a further option authenticated and associated with the roles to
on a permission query symmetric RBAC requires which they belong. This is an important attribute
the ability to select the target systems for which which can have signi cant impact on the usability
the review will be conducted. of a product in a speci c environment. This issue
is outside the scope of an access control model
7 OTHER RBAC ATTRIBUTES and is part of system architecture and mechanism
considerations.
This section discusses attributes of RBAC products
that are not covered or only partially covered in 7.3 Negative permissions
the NIST RBAC model. RBAC is a rich and The NIST model is based on positive permissions
open-ended technology. As such it would not be that confer the ability to do something on holders of
appropriate to pin down all aspects of RBAC in a the permission. The NIST model does not rule out
standard model. Some of the issues raised in this the use of so-called negative permissions which deny
section are not suitable for standardization. On access. Thus vendors are free to add this feature.
others there is lack of consensus to justify their Nevertheless vendors and users are cautioned that
standardization at the moment. use of negative permissions can be very confusing,
especially in presence of general hierarchies. The
7.1 Scalability uses to which they are put can often be better
Scalability is an important requirement for modern achieved by judicious use of constraints.
systems, especially with the tremendous growth of
the Internet. Some of the current products can meet 7.4 Nature of permissions
level 1 RBAC requirements but provide support The nature of permissions is not speci ed in the
for only a small number of roles such as 16 or 32. NIST RBAC model. Permissions can be ne-
Others are more scalable providing support for 100's grained (e.g., at the level of individual objects)
of roles. Clearly this is an important attribute in or coarse-grained (e.g., at the level of entire sub-
product selection. systems). They can be de ned in terms of primitive
The notion of scalability is multi-dimensional. operations such as read and write, or abstract
In RBAC we can have scalability with respect to operations, such as credit and debit. Permissions
number of roles, number of permissions, size of role can also be customized. For example, a Physician
roles can be granted permission to read medical require something to happen AS99]. The concept
records but only for those patients assigned to of obligation constraints is considered too new to
the individual doctor in question. The exact incorporate into a standard model at this point.
nature of permissions is determined by the nature
of the product. Operating systems, database 7.8 RBAC administration
management systems, work ow systems, network
management systems will all support dierent kinds The NIST RBAC model does not specify the autho-
of permissions. Standardization of permissions is rization for assigning users to roles, permissions to
beyond the scope of a general-purpose access control roles and roles to roles (in a role hierarchy), and for
model. revoking these assignments. Several models for this
purpose have been proposed in the literature. Some
7.5 Discretionary role activation of these are rooted in traditional discretionary ac-
cess control where the owner of a roles is allowed full
The NIST RBAC model does not specify the ability control over that role. Others centralize administra-
of a user to select which roles are activated in tive authority in a single security ocer role. A de-
a particular session. The only requirement is centralized administrative model based on adminis-
that it should be possible to allow a user to trative roles has been recently published SBM99].
activate multiple roles simultaneously. This rules Due to lack of consensus in this arena the NIST
out products that only allow use of one role at RBAC model does not incorporate an administra-
a time. Some existing products give no choice tive component.
to the user and activate all the users roles in a
session. Other products activate a default set of 7.9 Role revocation
roles and leave it up to the user's discretion to add
and subtract roles from this set. The NIST RBAC The semantics of role revocation is not speci ed
does not impose a requirement in this arena. It is in the NIST RBAC model. The main issue is the
a feature that vendors can use to distinguish their immediacy of revocation. When a user is revoked
products as they see t. from a role what happens to existing sessions where
the user has activated that role? Should the user
7.6 Role engineering be allowed to complete the session or should the
The NIST RBAC model does not provide guidelines revoked role be immediately deactivated from that
for deigning roles and assigning permissions and session? This is a dicult issue, particularly in
users to roles. This activity is called role engineer- distributed systems where the notion of doing some
ing. Eective use of RBAC in large-scale is strongly action immediately is itself hard to pin down. The
dependent on eective role engineering. However, NIST RBAC model does not specify revocation
this issue is outside the scope of the NIST RBAC behavior, but it is an important issue to which
model. vendors and users of RBAC products must pay
careful attention.
7.7 Constraints
The NIST RBAC model recognizes separation of 8 CONCLUSION
duty (SOD) constraints. Support for SOD is re- The driving motivation for RBAC is to simplify se-
quired at level 3. The exact forms of that that curity policy administration while facilitating the
need to be supported are not legislated in the NIST de nition of exible, customized policies. Over the
RBAC model. The NIST model distinguishes be- past nine years signi cant advancements have been
tween static and dynamic SOD. However, there are made in both the theoretical modeling and practical
many other forms of SOD that can be distinguished. implementation of RBAC features. Today RBAC is
For instance, concepts of role-centric, permission- becoming expected among large users and the num-
centric and user-centric SOD have been recently in- ber of vendors that are oering RBAC features is
troduced in the literature AS99] growing rapidly. This development continues with-
SOD is an example of a prohibition constraint out any general agreement as to what constitutes
which prevent something from happening. RBAC RBAC features. This paper is the rst attempt to
can also incorporate obligation constraints which develop an authoritative de nition of core RBAC
features for use in authorization management sys- partial orders are more powerful and exible, trees
tems. Although RBAC continues to be an evolving and inverted tree structures are the most common
technology, the RBAC features that were chosen to implementation and are included for that purpose.
be included within this paper represent a stable and Level 3, constrained RBAC, adds requirements for
well accepted set of features described in RBAC lit- the enforcement of separation of duties (SOD) poli-
erature and/or are beginning included within a wide cies. The exact form of SOD is left open by the
breath of commercial implementations. RBAC model. Two sub-levels 3a and 3b are de ned
Standardization over a core set of RBAC fea- similar to levels 2a and 2b requiring support for ar-
tures is expected to provide a multitude of bene ts. bitrary and limited hierarchies respectively. Level 4
These bene ts include a common set of benchmarks further extends these requirements to include an in-
for vendors, who are already developing RBAC terface for permission-role review with respect to a
mechanisms, to use in their product speci cations. de ned user or role. These requirements pertain to
It will give IT consumers, who are the principal ben- the type of data that is returned to the administra-
e ciary of RBAC technology, a basis for the creation tor, the ability to select direct or indirect permission
of uniform acquisition speci cation. In addition, assignment and for distributed systems the ability
this standardized RBAC model will promote the to select the target systems in which the permission
subsequent development of a standard RBAC API, review will be applied.
that would in turn promote the development of new
and innovative authorization management tools by References
guaranteeing interoperability and portability.
AS99] Gail-Joon Ahn and Ravi Sandhu. The
Although RBAC is often considered a single ac- RSL99 language for role-based separa-
cess control and authorization model, RBAC is in tion of duty constraints. In Proceed-
fact composed of a number of models each t for a ings of 4th ACM Workshop on Role-
speci c security management application. As such, Based Access Control, pages 43{54, Fair-
the NIST RBAC model has been organized into fax, VA, October 28-29 1999. ACM.
four separate levels of increasing functional capa-
bility, each with a speci c rationale for its deploy- CW87] D.D. Clark and D.R. Wilson. A com-
ment. The rst level, at RBAC de nes features parison of commercial and military com-
that are minimally required of all RBAC systems. puter security policies. In Proceedings of
at RBAC requires that user-role and permission- IEEE Symposium on Security and Pri-
role assignment to consist of a many-to-many rela- vacy, pages 184{194, Oakland, CA, May
tionship. Although this basic requirement can be 1987.
achieved using a simple group mechanism, not all
group mechanisms today are capable of meeting this FBK99] David F. Ferraiolo, John F. Barkley, and
requirement. In addition level 1 has a requirement D. Richard Kuhn. A role based access
for a user-role review feature. For a system to meet control model and reference implementa-
at RBAC requirements it must provide the capa- tion within a corporate intranet. ACM
bility to identify the users that are assigned to any Transactions on Information and Sys-
role as well as the roles that are assigned to any tem Security, 2(1), February 1999.
user. Level 2, hierarchical RBAC adds requirements FCK95] David Ferraiolo, Janet Cugini, and
for role hierarchies. Among RBAC features role hi- Richard Kuhn. Role-based access con-
erarchies are considered to be the most bene cial trol (RBAC): Features and motivations.
from an administrative eciency point of view and In Proceedings of 11th Annual Computer
are included within a number of commercial imple- Security Application Conference, pages
mentations. Level 2, recognizes two types of role 241{48, New Orleans, LA, December 11-
hierarchies - 2a, general hierarchies, to support the 15 1995.
arbitrary partial ordering of roles to serve as the hi-
erarchy and limited hierarchies, 2b, to allow for sim- FK92] David Ferraiolo and Richard Kuhn.
pler hierarchical structures such as trees or inverted Role-based access controls. In Pro-
trees. Although hierarchies composed of arbitrary ceedings of 15th NIST-NCSC National
Computer Security Conference, pages
 554{563, Baltimore, MD, October 13-16 ceedings of 4th Annual Computer Secu-
1992. rity Application Conference, pages 282{
286, Orlando, FL, December 1988.
GGF98] Virgil D. Gligor, Serban I. Gavrila, and
David Ferraiolo. On the formal de nition San93] Ravi Sandhu. Lattice-based access con-
of separation-of-duty policies and their trol models. IEEE Computer, 26(11):9{
composition. In Proceedings of IEEE 19, November 1993.
Symposium on Research in Security and
Privacy, pages 172{183, Oakland, CA, San97] Ravi Sandhu. Roles versus groups. In
May 1998. Proceedings of the 1st ACM Workshop
on Role-Based Access Control. ACM,
Gui95] Luigi Guiri. A new model for role- 1997.
based access control. In Proceedings of
11th Annual Computer Security Appli- San98a] Ravi Sandhu. Role activation hier-
cation Conference, pages 249{255, New archies. In Proceedings of 3rd ACM
Orleans, LA, December 11-15 1995. Workshop on Role-Based Access Con-
trol, pages 33{40, Fairfax, VA, October
Kuh97] D. Richard Kuhn. Mutual exclusion 22-23 1998. ACM.
of roles as a means of implementing
separation of duty in role-based access San98b] Ravi Sandhu. Role-based access control.
control systems. In Proceedings of 2nd In Zelkowitz, editor, Advances in Com-
ACM Workshop on Role-Based Access puters, Volume: 46. Academic Press,
Control, pages 23{30. ACM, Fairfax, VA, 1998.
November 6-7 1997. SBM99] Ravi Sandhu, Venkata Bhamidipati, and
NO99] Matunda Nyanchama and Sylvia Os- Qamar Munawer. The ARBAC97 model
born. The role graph model and con- for role-based administration of roles.
ict of interest. ACM Transactions on ACM Transactions on Information and
Information and System Security, 2(1), System Security, 2(1):105{135, February
February 1999. 1999.
NP90] M.N. Nash and K.R. Poland. Some SCFY96] Ravi Sandhu, Edward J. Coyne, Hal L.
conundrums concerning separation of Feinstein, and Charles E. Youman. Role-
duty. In Proceedings of IEEE Symposium based access control models. IEEE
on Security and Privacy, pages 201{207, Computer, 29(2):38{47, February 1996.
Oakland, CA, May 1990. SZ97] R. Simon and M. Zurko. Separation of
OSM00] Sylvia Osborn, Ravi Sandhu, and Qamar duty in role-based environments. In Pro-
Munawer. Con guring role-based access ceedings of 10th IEEE Computer Secu-
control to enforce mandatory and dis- rity Foundations Workshop, pages 183{
cretionary access control policies. ACM 194, Rockport, Mass., June 1997.
Transactions on Information and Sys- TDH92] T.C. Ting, S.A. Demurjian, and M.Y.
tem Security, 3(2), May 2000. Hu. Requirements, capabilities, and
RS98] Chandramouli Ramaswamy and Ravi functionalities of user-role based secu-
Sandhu. Role-based access control fea- rity for an object-oriented design model.
tures in commercial database manage- In C.E Landwehr and S. Jajodia, ed-
ment systems. In Proceedings of 21st itors, Database Security V: Status and
NIST-NCSC National Information Sys- Prospects. North-Holland, 1992.
tems Security Conference, pages 503{
511, Arlington, VA, October 5-8 1998.
San88] Ravi Sandhu. Transaction control ex-
pressions for separation of duties. In Pro-
Appendix A. The Alternate Model Level RBAC Functional Capabilities
1 Flat No No
In this appendix we present an alternate model 2a General Hierarchy No No
which recognizes that the four step sequence pre- 2b Limited Hierarchy No No
sented in the main body of the paper may not al- 3a General Hierarchy Yes No
ways be applied in practice. Features of later steps 3b Limited Hierarchy Yes No
in that sequence may be adopted prior to adopt- 4a General Hierarchy Yes Yes
ing features of earlier steps. Based on comments 4b Limited Hierarchy Yes Yes
received so far and our own re ections we feel this
alternate model presents a superior approach. It Table 3: Relationship Between the Original and
re ects the initial approach we had taken but then Alternate Models
abandoned in an attempt to formulate a strict or-
dering of RBAC levels. We have thus come around The alternate model also allows the following 5
full circle on this issue. For the moment we have possibilities.
refrained from changing the main body of the pa-
per since it has previously been circulated for com- RBAC Functional Capabilities
ments. It would be confusing at the workshop to Flat Yes No
change the paper so drastically. Flat No Yes
The alternate model does not require any new Flat Yes Yes
concepts as such. It is essentially a restructuring General Hierarchy No Yes
of what we have already presented. The alternate Limited Hierarchy No Yes
model is summarized below. Table 4: Additional Possibilities in the Alternate
Model

RBAC Functional Capabilities These 5 possibilities as such are not excluded in the
Role Role Role original model but at the same time are not given
Structure Constraints Symmetry any extra value. In particular there is only one Flat
RBAC in the original model but in the alternate
Flat No No model Flat RBAC can occur in four variations.
Limited Hierarchy Yes Yes The alternate model is also more extensible. As
General Hierarchy consensus develops we can move from a simple
Table 2: The Alternate Model No/Yes scale to a more discriminating scale for role
constraints and role symmetry. Moreover additional
RBAC functional capabilities can be recognized.
Although not explicitly shown above the require- Some of these are mentioned in Section while others
ments of Flat RBAC as shown in Table 1 are re- may emerge later.
quired in all cases. In addition the three RBAC The alternate model is more complex than the
functional capabilities of role structure, constraints
and symmetry are recognized. Role structure can original but captures the reality of RBAC more
be Flat, Limited Hierarchy or General Hierarchy in accurately.
sequence of increasing power. Role constraints and
role symmetry have a simple No/Yes choice with
Yes being the stronger one.
Altogether the alternate model allows for 12 pos-
sibilities. In the original model only 7 of these 12
are recognized. There is a straightforward map-
ping between the levels of the original model and
the RBAC functional capabilities of the alternate
model as shown below. In the tables below these
capabilites are presented in the same sequence as in
the table above.
Appendix B. What Next? preparing our nation for the future. For example,
we are leading a public process to develop the Ad-
Paths Toward a Voluntary Industry vanced Encryption Standard (AES), and developing
Consensus Standard for RBAC a government wide Public Key Infrastructure stan-
by Richard Kuhn and David Ferraiolo dard to serve 21st century security needs for both
government and industry.
From the level of interest in Role-Based Access We are particularly excited about this proposed
Control shown by the research community and RBAC consensus standard because the work would
in the marketplace, it is clear that RBAC is be consistent with and build on our own research
becoming an integral part of the global information eorts in developing and transferring to indus-
infrastructure. With the growing number of RBAC try Role-Based Access Control and other autho-
products on the market has come interest in rization management technologies. Today RBAC
a consensus speci cation, either as a de facto is becoming increasingly popular within commer-
or de jure standard. Such a standard would cially available Database Management, Enterprise
provide both vendors and buyers with better means Management, and Network Operating Systems. A
to compare RBAC products, and to specify the number of bene ts could result from a uniform,
features they oer. As employees of the Computer widely accepted model for RBAC. Standardization
Security Division (CSD) of the National Institute of is one means of establishing such a model. Al-
Standards and Technology (NIST) we are excited though advancements have been made at the plat-
at the prospect of working with Professor Ravi form and network operating system level, access
Sandhu, of George Mason University and other control mechanisms do not interoperate with one
interested parties towards a voluntary industry another, are ineective at serving the policy need of
consensus standard for RBAC. all sectors, and are dicult to manage, and prone
NIST is the United States' measurement and test to human error.
laboratory, whose mission is to strengthen the U.S. The need for the capabilities provided by RBAC
economy and improve the quality of life by work- is highlighted by a growing recognition of the threat
ing with industry, universities, and government or- of insider attacks and the potential for these attacks
ganizations to develop and apply technology, mea- to undermine the global information infrastructure.
surements, and standards for information technol- Insider attacks already account for over 70computer
ogy. NIST carries out this mission by working crime and cyberterrorism.4 Insiders have wider
with industry and government partners to develop access to sensitive resources, deeper knowledge of
and demonstrate tests, test methods, reference im- internal systems and greater opportunity to carry
plementations and data, proof of concept imple- out their plans. The majority of insider attacks
mentations, and other infrastructure technologies do not hinge on awed protocols or sophisticated
that are usable, secure, scalable, and interopera- cryptanalysis. Instead, they take advantage of gaps
ble. Within the area of computer security, NIST in enterprise security policies. A consensus RBAC
has speci c statutory responsibilities for develop- standard would represent a culmination of the
ing security standards and technology to assist Fed- research eorts of many and is meant to represent
eral agencies in the protection of sensitive unclas- leading edge technology in addressing the most
si ed systems. This is in addition to NIST's mis- likely target of insider attacks - enterprise security
sion of strengthening the U.S. economy { including policies.
improving the competitiveness of America's infor-
mation technology (IT) through performing secu- Standard RBAC provides an opportunity for a
rity research, standards development and providing common representation for access control models
sound guidance. The solutions that NIST develops and policies, making it a suitable foundation for
are made available to both public and private users a policy coordination system. Embedding RBAC
and are often complemented by an active Technol- in our network and database architectures is an
ogy Transfer program. innovative approach to managing security policies
in open environments.
NIST has long been active in developing Federal
standards and working in cooperation with private 4 F. Schneider (Ed.) "Trust in Cyberspace". National
sector standards organizations and universities in Academy Press, Washington, D.C., 1999.
 A variety of options are available for achieving a
standard de nition for RBAC, including:
National and International Standards Bodies :
The International Organization for Standardization
(ISO) provides mechanisms for developing consen-
sus standards, typically through adoption of a na-
tional standard. National bodies within ISO, such
as ANSI (USA), DIN (Germany), and AFNOR
(France), may develop standards that are then for-
warded to ISO for international adoption.
Professional Society Standards Bodies : The same
path is available for standards developed through
bodies such as the Institute of Electrical and Elec-
tronics Engineers. IEEE standards are typically de-
veloped with the participation of interested parties
from many nations. IEEE standards typically be-
gin with a base document proposed by one or more
organizations. Working groups that meet several
times a year then modify the document before it is
voted on by interested parties. After approval as
an IEEE standard, they may be put on track for
adoption as an ISO standard.
Industry Consortia : Within the information tech-
nology industry, a number of consortia have de-
veloped consensus speci cations that have such
widespread adoption that they have become de
facto standards. Consortia speci cations are devel-
oped by working groups consisting of parties from
member companies. Although not recognized by
ocial standards bodies, they are often developed
more quickly and achieve the same level of market
recognition as international standards.
Federal Information Processing Standards : De-
veloped by NIST, FIPS are U.S. government stan-
dards that are often adopted widely within industry.
The Data Encryption Standard (DES) is probably
the most widely recognized example. FIPS are pro-
posed by NIST, then progress through a comment
and revision before approval.

View publication stats