This is a potential security issue, you are being redirected to https://csrc.nist.gov.
Roles with different privileges and responsibilities have long been recognized in business organizations, and commercial computer applications dating back to at least the 1970s implemented limited forms of access constraints based on the user’s role within an organization. These role-based systems were relatively simple and application-specific. That is, there was no general-purpose model defining how access control could be based on roles, and little formal analysis of the security of these systems. The systems were developed by a variety of organizations, with no commonly agreed upon definition or recognition in formal standards.
A general-purpose role based access control model was proposed in 1992 by Ferraiolo and Kuhn, integrating features of existing application-specific approaches into a generalized role based access control model. This paper presented RBAC as an alternative to traditional Mandatory Access Control (MAC) and Discretionary Access Control (DAC), and gave a formal description, in terms of sets, relations and mappings, to define roles and role hierarchies, subject role activation, subject-object mediation, as well as constraints on user/role membership and role set activation. Three basic rules were required:
A key feature of this model is that all access is through roles. A role is essentially a collection of permissions, and all users receive permissions only through the roles to which they are assigned, or through roles they inherit through the role hierarchy. Within an organization, roles are relatively stable, while users and permissions are both numerous and may change rapidly. Controlling all access through roles therefore simplifies the management and review of access controls. The 1992 Ferraiolo and Kuhn model was extended in 1995 by Ferraiolo, Cugini, and Kuhn.
In 1996, Sandhu, Coyne, Feinstein, and Youman introduced a framework for RBAC models that incorporated the RBAC features described above in a modular arrangement. RBAC0 was defined as the base model, defined through users, roles, and permissions. RBAC1 includes RBAC0 but incorporates hierarchies as a partial order relationship between roles. RBAC2 also incorporates RBAC0, but adds constraints. RBAC1 and RBAC2 are independent of each other, in that a system may implement one without the other. RBAC3 is a fully-featured RBAC model, incorporating RBAC0, RBAC1, and RBAC2. RBAC3 is essentially equivalent to the 1992 Ferraiolo and Kuhn model with the exception that RBAC3 allows a partial order hierarchy while the Ferraiolo-Kuhn model defines the hierarchy as a rooted tree. In object-oriented terms, the 1996 SCFY model can be thought of as incorporating multiple inheritance while Ferraiolo-Kuhn uses single inheritance.
There is a superficial similarity between RBAC roles and traditional groups. As normally implemented, a group is a collection of users, rather than a collection of permissions, and permissions can be associated with both users and the groups to which they belong. The ability to tie permissions directly to users in a group-based mechanism can be regarded as a "loophole" that makes it difficult to control user-permission relationships. RBAC requires all access through roles, and permissions are connected only to roles, not directly to users. Another aspect of RBAC that distinguishes it from traditional group mechanisms is the concept of a session, which allows activation of a subset of roles assigned to a user. Core RBAC includes those systems with a robust group/ACL mechanism that supports the construction of a many-to-many relation among users and permissions.
RBAC is a separate and distinct model from MAC and DAC, but a number of relationships have been discovered. In particular, it has been shown that RBAC can simulate MAC and DAC , and that MAC can be used to implement RBAC  when the role hierarchy is a tree rather than a partial order.
RBAC is well suited to handling "separation of duty" requirements, and was in fact designed with SoD in mind. This site contains several papers addressing SoD, and the RBAC standard covers this topic extensively (see "What is the RBAC standard", below).
Questions have also been raised as the suitability of RBAC for other relationships. For example, a 2008 discussion of the RBAC standard includes the following concern:
"However, in order for that doctor, Dr. X, to view the medical charts (electronically) of a particular patient, Patient Y, the good doctor not only needs to have a "Doctor" role, but also needs to have the "Attending Doctor" role WITH RESPECT TO Patient Y. In other words, the Access Control around the medical charts is based on a specific relationship established between Dr. X and Patient Y, that could be expressed as a relationship-based role."
This type of situation was explicitly addressed in the 1992 RBAC model, which grants access 'only if', not 'if' or 'if and only if' the role requirements are met (an extremely important distinction). This was done to allow additional constraints to be added at access time. No implementation details were specified for how to handle the additional constraints, since these would vary widely with the application and type of constraint. The RBAC standard, as the 1992 model, is designed to allow designers to add constraints to handle these relationships. In other words, nothing in the RBAC model will interfere with adding these constraints. The standard could be amended to add the means to handle relationships like those suggested above, if there is sufficient community interest, and if there is a sufficiently general mechanism that addresses a wide variety of industries.
In 2000, NIST called for a unified standard for RBAC, integrating the Ferraiolo-Kuhn 1992 model with the RBAC framework introduced by Sandhu et al. in 1996. This proposal was published by Sandhu, Ferraiolo, and Kuhn and presented at the ACM 5th Workshopon Role Based Access Control. Following debate and comment within the RBAC and security communities, NIST made revisions and proposed a U.S. national standard for RBAC through the International Committee for Information Technology Standards (INCITS), the primary U.S. body for developing standards in information and communications technology. INCITS is also the American National Standards Institute’s (ANSI) Technical Advisory Group for ISO/IEC Joint Technical Committee 1, which is responsible for IT standardization at the international level. In 2004, the standard received ballot approval and was adopted as INCITS 359-2004.
Standard is in two parts:
Since the 1990s, an extensive body of scholarly work has been published on all aspects of RBAC. As of 2006, more than 6,000 articles on various aspects of RBAC are listed by Google Scholar. Some early results are given below.
RELATIONSHIP BETWEEN RBAC, MAC, AND DAC
SEPARATION OF DUTY
Rudimentary forms of role based access control were implemented in a variety of ad hoc forms on many systems beginning in the 1970s. RBAC as used today derives from the model proposed by Ferraiolo and Kuhn (1992) and the model framework of Sandhu, Coyne, Feinstein, and Youman (1996). The timeline below traces the evolution of today's RBAC.