IEEE Computer, Volume 29, Number 2, February 1996, pages 38-47. y z Role-Based Access Control Mo dels ' k k k Ravi S. Sandhu , Edward J. Coyne , Hal L. Feinstein and Charles E. Youman Revised Octob er 26, 1995 Abstract This article introduces a family of reference mo dels for role- based access control (RBAC) in which p ermissions are asso ciated with roles, and users are made members of appropriate roles. This greatly simplifes management of p ermissions. Roles are closely related to the concept of user groups in access control. However, a role brings together a set of users on one side and a set of p ermissions on the other, whereas user groups are typically defned as a set of users only. The basic concepts of RBAC originated with early multi-user com- puter systems. The resurgence of interest in RBAC has b een driven by the need for general-purp ose customizable facilities for RBAC and the need to manage the administration of RBAC itself. As a consequence RBAC facilities range from simple to complex. This article describ es a novel framework of reference mo dels to systematically address the diverse comp onents of RBAC, and their interactions. Keywords: security, access control, roles, mo dels * This pap er has b een accepted for publication in IEEE Computer. y All corresp ondence should b e addressed to Prof. Ravi Sandhu, ISSE Department MS 4A4, George Mason University, Fairfax, Va 22030. Phone: 703-993-1659, fax: 703-993-1638, email: [email protected]. z This work is funded in part by contracts 50-DKNA-4-00122 and 50-DKNB-5-00188 from the National Institute of Standards and Technology. The work of Ravi Sandhu is also supp orted by grant CCR-9503560 from the National Science Foundation. ' SETA Corp oration and George Mason University k SETA Corp oration 1 INTRODUCTION The concept of role-based access control (RBAC) b egan with multi-user and multi- application on-line systems pioneered in the 1970s. The central notion of RBAC is that p ermissions are asso ciated with roles, and users are assigned to appropriate roles. This greatly simplifes management of p ermissions. Roles are created for the various job functions in an organization and users are assigned roles based on their resp onsibilities and qualifcations. Users can b e easily reassigned from one role to another. Roles can b e granted new p ermissions as new applications and systems are incorp orated, and p ermissions can b e revoked from roles as needed. A role is prop erly viewed as a semantic construct around which access control p ol- icy is formulated. The particular collection of users and p ermissions brought together by a role is transitory. The role is more stable b ecause an organization's activities or functions usually change less frequently. Several distinct motivations for constructing a role are discussed b elow. A role can represent comp etency to do sp ecifc tasks, such as a physician or a pharmacist. A role can emb o dy authority and resp onsibility, e.g., pro ject sup ervisor. Authority and resp onsibility are distinct from comp etency. Jane Do e may b e comp etent to head several departments, but is assigned to head one of them. Roles can refect sp ecifc duty assignments that are rotated through multiple users, e.g., a duty physician or shift manager. RBAC mo dels and implementations should b e able to conveniently accommo date all of these manifestations of the role concept. A recent study by NIST [1] demonstrates that RBAC addresses many needs of the commercial and government sectors. In this study of 28 organizations, access control requirements were found to b e driven by a variety of concerns including cus- tomer, sto ckholder and insurer confdence, privacy of p ersonal information, preventing unauthorized distribution of fnancial assets, preventing unauthorized usage of long- distance telephone circuits, and adherence to professional standards. The study found that many organizations based access control decisions on "the roles that individual users take on as part of the organization." Many organizations preferred to centrally control and maintain access rights, not so much at the system administrator's p er- sonal discretion but more in accordance with the organization's protection guidelines. The study also found that organizations typically viewed their access control needs as unique and felt that available pro ducts lacked adequate fexibility. Other evidence of strong interest in RBAC comes from the standards arena. Roles are b eing considered as part of the emerging SQL3 standard for database management systems, based on their implementation in Oracle 7. Roles have also b een incorp orated in the commercial security profle of the draft Common Criteria [2]. RBAC is also well matched to prevailing technology and business trends. A numb er of pro ducts supp ort some form of RBAC directly, and others supp ort closely related concepts, such as user groups, that can b e utilized to implement roles. 1 Notwithstanding the recognized usefulness of the RBAC concept, there is little agreement on what RBAC means. As a result RBAC is an amorphous concept inter- preted in diferent ways by various researchers and system developers, ranging from simple to elab orate and sophisticated. This pap er describ es a novel framework of four reference mo dels developed by the authors to provide a systematic approach to understanding RBAC, and to cat- egorizing its implementation in diferent systems. Our framework also separates the administration of RBAC from its use for controlling access to data and other re- sources. 2 BACKGROUND AND MOTIVATION A ma jor purp ose of RBAC is to facilitate security administration and review. Many commercially successful access control systems for mainframes implement roles for security administration. For example, an op erator role could access all resources but not change access p ermissions, a security-ofcer role could change p ermissions but have no access to resources, and an auditor role could access audit trails. This administrative use of roles is also found in mo dern network op erating systems, e.g., Novell's NetWare and Microsoft Windows NT. Recent resurgence of interest in RBAC has fo cussed on general supp ort of RBAC at the application level. In the past, and to day, sp ecifc applications have b een built with RBAC enco ded within the application itself. Existing op erating systems and environments provide little supp ort for application-level use of RBAC. Such supp ort is b eginning to emerge in pro ducts. The challenge is to identify application-indep endent facilities that are sufciently fexible, yet simple to implement and use, to supp ort a wide range of applications with minimal customization. Sophisticated variations of RBAC include the capability to establish relations b etween roles as well as b etween p ermissions and roles and b etween users and roles. For example, two roles can b e established as mutually exclusive, so the same user is not allowed to take on b oth roles. Roles can also take on inheritance relations, whereby one role inherits p ermissions assigned to a diferent role. These role-role relations can b e used to enforce security p olicies that include separation of duties and delegation of authority. Heretofore, these relations would have to b e enco ded into application software; with RBAC, they can b e sp ecifed once for a security domain. With RBAC it is p ossible to predefne role-p ermission relationships, which makes it simple to assign users to the predefned roles. The NIST study [1] indicates that p ermissions assigned to roles tend to change relatively slowly compared to changes in user membership of roles. The study also found it desirable to allow administra- tors to confer and revoke membership to users in existing roles without giving these administrators authority to create new roles or change role-p ermission assignments. 2 Assignment of users to roles will typically require less technical skill than assignment of p ermissions to roles. It can also b e difcult, without RBAC, to determine what p ermissions have b een authorized to what users. Access control p olicy is embo died in various comp onents of RBAC such as role- p ermission, user-role and role-role relationships. These comp onents collectively de- termine whether a particular user will b e allowed to access a particular piece of data in the system. RBAC comp onents may b e confgured directly by the system owner or indirectly by appropriate roles as delegated by the system owner. The p olicy en- forced in a particular system is the net result of the precise confguration of various RBAC comp onents as directed by the system owner. Moreover, the access control p olicy can evolve incrementally over the system life cycle, and in large systems it is almost certain to do so. The ability to mo dify p olicy to meet the changing needs of an organization is an imp ortant b eneft of RBAC. Although RBAC is p olicy neutral, it directly supp orts three well-known security principles: least privilege, separation of duties, and data abstraction. Least privilege is supp orted b ecause RBAC can b e confgured so only those p ermissions required for the tasks conducted by members of the role are assigned to the role. Separation of duties is achieved by ensuring that mutually exclusive roles must b e invoked to complete a sensitive task, such as requiring an accounting clerk and account manager to participate in issuing a check.