Publications on Role Based Access Control (RBAC)

• Information Technology — Role Based Access Control. Document Number: ANSI/INCITS 359-2004. American National Standard for Information Technology. From InterNational Committee for Information Technology Standards (formerly NCITS). 03-Feb-2004. 56 pages. Available in download in PDF format for $18.00 (USD). "This product replaces INCITS 359 Draft."

• American National Standard for Information Technology — Role Based Access Control. Draft. "Proposed voluntary consensus standard." Secretariat: Information Technology Industry Council (ITI). BSR INCITS 359. 2003-04-04. 49 pages. Comments/questions to: Rick Kuhn (NIST). [cache]

• Role-Based Access Control. By David F. Ferraiolo, D. Richard Kuhn, and Ramaswamy Chandramouli. Artech House, 2003. ISBN 1-58053-370-1. 338 pages. See the sample chapter 2, "Access Control Policy, Models, and Mechanisms: Concepts and Examples." Also: (1) summary from Artech House; (2) summary and TOC from NIST; (3) review by Makan Pourzandi, October 24, 2003; (4) review by Tolga Acar, June 5, 2003.

• XACML Profile for Role Based Access Control (RBAC). OASIS XACML TC, Committee Draft. Version 01. 13-February-2004. Document identifier: 'cs-xacml-rbac-profile-01'. Edited by Anne Anderson (Sun Microsystems). Produced by the OASIS Extensible Access Control Markup Language TC. See the Minutes of the 5 February 2004 XACML TC Meeting at which the TC voted to make the XACML RBAC Profile a Committee Draft. [source PDF]

• "XML-Based Specification for Web Services Document Security." By Rafae Bhatti (Electrical and Computer Engineering, Purdue University), Elisa Bertino (Director of Research, CERIAS, Purdue University), Arif Ghafoor (Professor of Electrical and Computer Engineering, Purdue University); James B.D. Joshi (Department of Information Sciences and Telecommunications, University of Pittsburg). In IEEE Computer Volume 37, Number 4 (April 2004), pages 41-49. See the abstract and excerpt.

• "Access Control in Dynamic XML-based Web-Services with X-RBAC." By Rafae Bhatti, James B. D. Joshi, Elisa Bertino, and Arif Ghafoor. Accepted for publication in Proceedings of the First International Conference on Web Services (ICWS) (Las Vegas, June 23-26, 2003). 7 pages. "Policy specification for securing Web services is fast emerging as a key research area due to rapid proliferation of Web services in modern day enterprise applications. Whilst the use of XML technology to support these Web services has resulted in their tremendous growth, it has also introduced a new set of security challenges specific to these Web services. Though there has been recent research in areas of XML-based document security, these challenges have not been addressed within the XML framework. In this paper, we present X-RBAC, an XML-based RBAC policy specification framework for enforcing access control in dynamic XML-based Web services. An X-RBAC system has been implemented as a Java application, and is based on a specification language that addresses specific security requirements of these Web services. We discuss the salient features of the specification language, and present the software architecture of our X-RBAC system..."

• "Dependencies and Separation of Duty Constraints in GTRBAC." By James B. D. Joshi, Elisa Bertino, Basit Shafiq, and Arif Ghafoor. Accepted for publication in the Proceedings of the Eighth ACM Symposium on Access Control Models and Technologies (Como, Italy, June 2-3, 2003). "Role based access control (RBAC) has emerged as a promising alternative to traditional discretionary and mandatory access control (DAC and MAC) models, which have some inherent limitations. Several key features such as policy neutrality, support for least privilege, efficient access control management, are associated with RBAC models. Such features make RBAC better suited for handling access control requirements of diverse organizations. Furthermore, the concept of role is associated with the notion of functional roles in an organization, and hence RBAC models provide intuitive support for expressing organizational access control policies. RBAC models have also been found suitable for addressing security issues in the Internet environment, and have shown prospects for supporting secure interoperation in a heterogeneous multidomain environment. One of the important aspects of access control is that of time constraining accesses to limit resource use. Such constraints are essential for controlling time-sensitive activities that may be present in various applications such as workflow management systems (WFMSs). Tasks in a WFMS may be time dependent and need to be executed in some order... A Generalized Temporal Role Based Access Control (GTRBAC) model that captures an exhaustive set of temporal constraint needs for access control has recently been proposed. GTRBAC's language constructs allow one to specify various temporal constraints on role, user-role assignments and role-permission assignments. In this paper, we identify various time-constrained cardinality, control flow dependency and separation of duty constraints (SoDs). Such constraints allow specification of dynamically changing access control requirements that are typical in today's large systems. In addition to allowing specification of time, the constraints introduced here also allow expressing access control policies at a finer granularity. The inclusion of control flow dependency constraints allows defining much stricter dependency requirements that are typical in workflow types of applications... Our approach to separation of duty constraints is based on the fact that the notion of conflict between elements in a set is often associated with another set. This allows us to consider SoDs that are of much finer-granularity. We have shown that the separation duty constraints identified in the literature can be easily expressed by a subset of our separation duty constraint expressions. One key future work that we plan to pursue is to develop a SQL or XML like language to specify the GTRBAC constraints. Another direction we plan to investigate is to use GTRBAC for workflow type of systems..."

• "Schema Based XML Security: RBAC Approach." By Xinwen Zhang, Jaehong Park, and Ravi Sandhu. Presented at the Seventeenth IFIP 11.3 Working Conference on Data and Application Security (Estes Park, Colorado, USA, August 4-6, 2003). "As a platform-independent solution, XML is going to be used in many environments such as application integration andWeb Services. Security of XML instance is a basic problem, especially in enterprise with large number of users and XML objects as well as complex authorizations administration. In this paper, a role-based access control (RBAC) model based on XML Schema is proposed. RBAC has been proven to be efficient to improve security administration with flexible authorization management. XML Schema is a specification to define format and contents of XML instance. Access control based on a schema will be transported to all its instances. As a proposed alternate of XML Document Type Definition (DTD), XML Schema supports complex constraints for XML components, such as elements, attributes, datatypes and groups. Also, XML Schema provides a mechanism to build rich reuse relationships between schemas and elements. These will be applied in reusable permissions in our model, which efficiently simplify the security administration. Based on these features fine-grained access control can be achieved. At the same time, our model also supports instances-level authorization naturally, which provides a uniform mechanism for XML security. A abstract implementation is presented in this paper for our proposed model..." See also the publications list of Xinwen Zhang, and "PBDM: A Flexible Delegation Model in RBAC,", presented at the Eighth ACM Symposium on Access Control Models and Technologies (SACMAT 2003).

• "Proposed NIST Standard for Role-Based Access Control." By David F. Ferraiolo (National Institute of Standards and Technology), Ravi Sandhu (SingleSignOn.Net and George Mason University), Serban Gavrila (VDG Incorporated), with D. Richard Kuhn And Ramaswamy Chandramouli (National Institute of Standards and Technology). In ACM Transactions on Information and System Security (TISSEC) Volume 4, Number 3 (August 2001), pages 224-274. "In this article we propose a standard for role-based access control (RBAC). Although RBAC models have received broad support as a generalized approach to access control, and are well recognized for their many advantages in performing large-scale authorization management, no single authoritative definition of RBAC exists today. This lack of a widely accepted model results in uncertainty and confusion about RBAC's utility and meaning. The standard proposed here seeks to resolve this situation by unifying ideas from a base of frequently referenced RBAC models, commercial products, and research prototypes. It is intended to serve as a foundation for product development, evaluation, and procurement specification. Although RBAC continues to evolve as users, researchers, and vendors gain experience with its application, we feel the features and components proposed in this standard represent a fundamental and stable set of mechanisms that may be enhanced by developers in further meeting the needs of their customers." [cache]

From the INCITS Announcement

The InterNational Committee for Information Technology Standards (INCITS) today announced that the Role Based Access Control (RBAC) standard has been approved by the American National Standards Institute (ANSI). The standard is designated as ANSI INCITS 359-2004, American National Standard for Information Technology — Role Based Access Control, and can be purchased through the INCITS Web site.

Role Based Access Control has become the predominant model for advanced access control because it reduces the complexity and cost of security administration in large networked applications. Many information technology vendors have incorporated RBAC into their product line, and the technology is finding applications in areas ranging from health care to defense, in addition to the mainstream commerce systems for which it was designed. The National Institute of Standards and Technology (NIST) initiated the development of the standard via the INCITS fast track process.

This standard describes RBAC features that have achieved acceptance in the commercial marketplace. It includes a reference model and functional specifications for the RBAC features defined in the reference model. It is intended for:

1. software engineers and product development managers who design products incorporating access control features
2. managers and procurement officials who seek to acquire computer security products with features that provide access control capabilities based on commonly known and understood terminology and functional specifications

"The standard provides users and vendors of information technology products with a coherent and uniform definition of RBAC features and we anticipate that this first ever RBAC standard can serve as the basis for further international standardization of RBAC by INCITS," explained Susan Zevin, Acting Director of the Information Technology Laboratory at the National Institute for Standards and Technology (NIST).

"This RBAC standard is structured so that RBAC profiles could be developed for specific applications, such as the protection of critical infrastructure, and we welcome all interested parties to join INCITS to further progress RBAC standardization," said Karen Higginbottom, INCITS Executive Board Chair and Director of Standards Initiatives in Hewlett-Packard's Office of Strategy and Technology. The new RBAC standard is already being used by the Organization for the Advancement of Structured Information Standards (OASIS) to define RBAC building blocks for web services using the popular XML language.

Ed Reed, the Security Tzar at Novell, said, "Novell welcomes the publication of this standard. We look forward to the widespread industry adoption of RBAC as a standard in applications and infrastructure services that this will encourage."

OASIS XACML Profile for Role Based Access Control (RBAC)

Members of the OASIS XACML TC had the opportunity to work with the NIST RBAC team as NIST was completing a final review of what has now become the ANSI RBAC standard. A series of meetings was also held with the NIST RBAC team during the review of the XACML RBAC Profile. General approval of the XACML Profile was given by the NIST team, as explained in meeting minutes. The contributions of the NIST RBAC standard editorial team are acknowledged in the published XACML Profile for Role Based Access Control (RBAC) Committee Draft, including John Barkley (NIST), Ramaswamy (Mouli) Chandramouli (NIST), David Ferraiolo (NIST), Rick Kuhn (NIST), and Serban Gavrila (VDG Inc). See the full XACML Profile bibliographic reference above.

The XACML Profile for Role Based Access Control (RBAC) Committee Draft uses the ANSI terminology and model, and completely implements the functionality described in the ANSI RBAC standard. The RBAC model described in the ANSI standard is belived to be consistent with consensus modern understandings of RBAC. The XACML Profile does not, however, support the ANSI RBAC APIs. A limitation of the ANSI RBAC standard is in its APIs, which were designed for small, special-purpose, turnkey systems, and are not thought to be implementable on top of modern [2004] operating systems. [adapted from information supplied by Anne.Anderson]

Excerpted from the XACML Profile Committee Draft: "This [XACML Profile for Role Based Access Control (RBAC)] specification defines a profile for the use of the OASIS Extensible Access Control Markup Language (XACML) to meet the requirements for role based access control (RBAC) as specified in [the Proposed ANSI Standard, BSR INCITS 359] available from NIST, Role Based Access Control. Use of this Profile requires no changes or extensions to standard XACML Versions 1.0 or 1.1.

This specification begins with a non-normative explanation of the building blocks from which the RBAC solution is constructed. A full example illustrates these building blocks. The specification then discusses how these building blocks may be used to implement the various elements of the RBAC model presented in [the Proposed ANSI standard]. Finally, the normative section of the specification describes compliant uses of the building blocks in implementing an RBAC solution. This proposal assumes the reader is somewhat familiar with XACML...

Role: In this specification, roles are expressed as XACML Subject Attributes. There is one exception: in a Role Assignment <PolicySet> or <Policy>, the role appears as a Resource Attribute... Role attributes may be expressed in either of two ways, depending on the preferences of the application environment. In some environments there may be a small number of 'role attributes', where the name of each such attribute is some name indicating 'role', and where the value of each such attribute indicates the name of the role held. For example, in this first type of environment, there may be one 'role attribute' having the identifier urn:someapp:attributes:role. The possible roles are values for this one attribute, and might be officer, manager, and employee. This way of expressing roles works best with the XACML way of expressing policies.

Alternatively, in other application environments, there may be a number of different attribute identifiers, each indicating a different role. For example, in this second type of environment, there might be three attribute identifiers: urn:someapp:attributes:officer-role, urn:someapp:attributes:manager-role, and urn:someapp:attributes:employee-role. In this case the value of the attribute may be empty or it may contain various parameters associated with the role. XACML policies can handle roles expressed in this way, but not as naturally as in the first way.

XACML supports multiple subjects per access request, indicating various entities that may be involved in making the request. For example, there is usually a human user who initiates the request, at least indirectly. There are usually one or more applications or code bases that generate the actual low-level request on behalf of the user. There is some computing device on which the application or code base is executing, and this device may have an identity such an IP address... In this Profile, a role attribute may be associated with any of the categories of subjects involved in making an access request...

Multi-Role Permissions: In this Profile, it is possible to express policies where a user must hold several roles simultaneously in order to gain access to certain permissions. For example, changing the care instructions for a hospital patient may require that the Subject performing the action have both the physician role and the staff role..."

RBAC and Web Services: An Example

An article "XML-Based Specification for Web Services Document Security" was published in IEEE Computer Volume 37, Number 4 (April 2004), illustrating the use of RBAC security methods. Excerpts from the paper:

"Document security in XML-based Web services has become increasingly important for managing secure business transactions over the Web. The authors propose an XML-based access control specification language to address this security challenge... [This] XML-based access control specification language addresses a new set of challenges that traditional security models do not address...

The secure documents that XML-based Web services disseminate encompass diverse subjects and objects related to the applications. Object heterogeneity can exist either as abstract concepts or as knowledge embodied in the information that requires protection. For example, the enormous volume of data in a digital library Web service makes exercising access control for high-level concepts rather than for individual objects highly desirable. Further, information content can evolve with time as the library adds new documents and removes or updates old ones, introducing scalability problems in privilege management...

Our XML-based specification language incorporates these content- and context-based dynamic security requirements for documents in XML-based Web services. Our approach provides access control with an element-level granularity for Web services with specific document security requirements and enforces concept-level access control on the underlying data repositories. We base our specification on the role-based access control (RBAC) model, which is particularly suitable for Web applications because it can define a diverse set of access control policies... A key advantage of the RBAC model is that it simplifies authorization administration by assigning permissions to users through roles. Thus, it adds a layer of abstraction between users and their permissions...

The RBAC model has five primary elements: users, roles, permissions, operations, and objects. These elements are related through set-relations and functions. Permissions are composed of an object-to-operations mapping. Our specification captures both the core RBAC model semantics and extensions to the core model, including role hierarchies and separation of duty constraints. Our model uses a location-based approach to capture the context information. A session parameter records the domain from which the user requests access. In addition to the requesting user's domain, the session schema also contains attributes that capture the user's activity profile such as login_time, login_date, and the session's duration. The model processes such information dynamically and incorporates it into access decisions in which context information can be an important decision parameter...

Our XML-based specification language models the RBAC elements and incorporates the functional specifications according to the NIST RBAC standard. Our specification models the five basic RBAC elements and their relationships. We use XML to generate schema definitions for the user, role, and permission elements. Schema definition is unnecessary for the operation and object elements because the specification includes them in a permission definition according to the NIST standard, so the permission schema captures their relationship with other RBAC elements...

Our approach does not substitute for the features these frameworks already incorporate, such as Web services security specifications or the passport authentication system. Instead, it complements them by providing a policy specification and enforcement mechanism that could be implemented using existing standards, such as WS-Policy, then incorporated within these XML-based frameworks to meet the target organization's specific needs. Thus, the model we propose is both modular enough for use with existing Web services security frameworks and extensible enough for development into a complete Web services security framework..."

Related XML-Based Technology: Role-Based Trust-Management Markup Language (RTML)

"RTML: A Role-Based Trust-Management Markup Language." CERIAS Tech Report 2004-03. By Ninghui Li (Center for Education and Research in Information Assurance and Security, Purdue University); John C. Mitchell (Department of Computer Science, Stanford Universioty); William H. Winsborough (Center for Secure Information Systems, George Mason University); Kent E. Seamons, Michael Halcrow, and Jared Jacobson (Computer Science Department, Brigham Young University). 21 pages (with 29 references). See also the XML Schema [source].

We present RTML version 1, a Role-based Trust-management Markup Language, which is an XML-based data representation of the RT framework. RTML extends the original design of RT, adding the following features: new data types to encode permissions involving structured resources and ranges, restrictive inheritance of roles for flexible refinement of permissions, and notions of identity roles and identity-based roles to address the issue of enforcing Separation of Duty policies when a physical user holds multiple keys.

RTML enables the deployment of the RT framework. Compared with systems like SPKI/SDSI and KeyNote, it has the following distinguishing features. RTML is designed with a logic-based semantics foundation. RTML directly addresses the issue of vocabulary agreement and uses strongly typed credentials, help reducing potential errors in writing credentials and unintended interactions among credentials. RTML supports more flexible delegation, including the ability to delegate to principals that have certain properties and to control the scope of a delegation. RTML also supports Separation of Duty in a more expressive way..."

Related Technology: xoRBAC

xoRBAC provides an Role-Based Access Control (RBAC) service that can be reused on Unix and Windows systems within applications providing C or Tcl linkage. xoRBAC is well suited to be used within a component framework. Component frameworks consist of reusable components that can be glued together with application specific semantics to form arbitrary applications. The xoRBAC component is implemented with XOTcl which offers a dynamic programming environment for rapid application development. xoRBAC Version 0.6.1 features include: (1) Many-to-many user-role and permission-role assignment and revocation; (2) (3) Arbitrary (DAG) role-hierarchies — permission-inheritance; (4) Definition of conditional permissions via context constraints; (5) Static separation of duties constraints for both roles and permissions — SSD constraint-inheritance via the role-hierarchy; (6) Maximum and minimum cardinalities for both roles and permissions; (7) Extensive review functions (introspection), e.g., subject-role review, permission-role review, subject-permission review; (8) Serialization (import and export) of xoRBAC policies as RDF metadata in XML Syntax; (9) Graphical administration tool supporting all xoRBAC functions..."

"Conflict Checking of Separation of Duty Constraints in RBAC — Implementation Experiences." By Mark Strembeck (Department of Information Systems, New Media Lab, Vienna University of Economics and BA, Austria).

"Separation of duty constraints define mutual exclusion relations between two entities (e.g., two permissions). Thus, a software component that supports the definition of separation of duty constraints implicitly requires a means to control their definition and to ensure the consistency of the resulting runtime structures. In this paper, we present our experiences with the implementation of conflict-checking methods for separation of duty constraints in the XORBAC access control service concludes the paper...

In access control, separation of duty constraints enforce conflict of interest policies. Conflict of interest arises as a result of the simultaneous assignment of two mutual exclusive permissions or roles to the same subject. Mutual exclusive roles or permissions result from the division of powerful rights or responsibilities to prevent fraud and abuse. An example is the common practice to separate the lcontrollern role and the lchief buyern role in medium-sized and large companies. A particular access control specification (an access control policy rule set and the corresponding subject-assignment relations) is said to be safe iff no subject can obtain an 'unauthorized' right. In other words, no conflicting permission can ever be assigned to the current permission-set of a particular subject, neither directly nor via a role. However, since the verification of the safety property for general access control models, like role-based access control (RBAC), is not decidable, constraints are an attempt to enforce the safety property via explicit modeling-level artifacts.

...Access control deals with the elicitation, specification, maintenance, and enforcement of authorization policies in software-based systems. In order to allow for an (automated) enforcement of authorization policies, the high-level control objectives of a system need to be mapped to the structures provided by an access control model. Access control model provide a framework for the definition of authorization policies. The three most important classes of access control models are discretionary access control (DAC), mandatory access control (MAC), and role-based access control (RBAC). DAC is sometimes criticized as conceding too many liberties to the rights-manager, while MAC commonly is regarded as being too restrictive for most applications. RBAC offers a promising alternative.

In recent years RBAC (together with various extensions) has developed into the de facto standard for access control in both research and industry. One of the advantages of RBAC is being a general access control model. This means that a sophisticated RBAC-service may be configured to enforce many different access control policies, including DAC- or MAC-based policies. A central idea in RBAC is to support constraints on almost all parts of an RBAC model (e.g., permissions, roles, or assignment relations) to achieve high flexibility. Static and dynamic separation of duty are two of the most common types of RBAC constraints. The XORBAC component provides an RBAC service that can be used on Unix and Windows systems with applications providing C or Tcl linkage. XORBAC is implemented with XOTcl. While originally developed as an RBAC service, XORBAC was extended to provide a multi-policy access control system which can enforce RBAC, as well as DAC or MAC based policies including conditional permissions... XORBAC is publicly available from http://www.xotcl.org..."

Principal References

• INCITS:
  • Announcement 2004-04-02: "INCITS Announces New Standard for Role Based Access Control. First-of-its-kind Cyber Security Standard Supports Commercial and Homeland Security Applications."
  • InterNational Committee for Information Technology Standards (INCITS). "INCITS is the primary U.S. focus of standardization in the field of Information and Communications Technologies (ICT), encompassing storage, processing, transfer, display, management, organization, and retrieval of information. As such, INCITS also serves as ANSI's Technical Advisory Group for ISO/IEC Joint Technical Committee 1. JTC 1 is responsible for International standardization in the field of Information Technology"
  • Information Technology — Role Based Access Control. Document Number: ANSI/INCITS 359-2004. February 2004.
• NIST:
  • NIST Role Based Access Control (RBAC) web site. Principal investigators include David Ferraiolo, Rick Kuhn, Ramaswamy Chandramouli, and John Barkley.
  • American National Standard for Information Technology — Role Based Access Control. Proposed voluntary consensus standard. Superseded by ANSI/INCITS 359-2004.
  • Additional references: see citations on the home page of Rick Kuhn, Computer Security Division, National Institute of Standards and Technology (NIST).
  • NIST RBAC email contact: rbac-info@nist.gov
• OASIS:
  • XACML Profile for Role Based Access Control (RBAC). Committee Draft. February 2004.
  • OASIS Extensible Access Control Markup Language (XACML) TC web site
• ACM SACMAT:
  • Accepted papers for SACMAT 2004. ACM Symposium on Access Control Models and Technologies. At least ten (10) of the accepted papers address issues of role based access control. "SACMAT 2004 is the fourth of a successful series of symposiums that continue the tradition, first established by the ACM Workshop on Role-Based Access Control, of being the premier forum for presentation of research results and experience reports on leading edge issues of access control, including models, systems, applications, and theory."
  • SACMAT 2003 Accepted Papers. Eighth ACM Symposium on Access Control Models and Technologies (SACMAT). June 2-3, 2003. Villa Gallia, Como, Italy. Sponsored by the ACM Special Interest Group on Security, Audit and Control (SIGSAC).
• See also: Purdue Center for Education and Research in Information Assurance and Security (CERIAS).
• See also: XML and Security Standards - Reference listing.