| | 1 | == RBAC Refeernce Model == |
| | 2 | From pages 2 and 3 of [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/ANSI+INCITS+359-2004.pdf American National Standard for Information Technology - Role Based Access Control]], American National Standards Institute Inc, ANSI INCITS 359-2004, February 2004: |
| | 3 | |
| | 4 | The RBAC reference model is defined in terms of four model components - Core RBAC, Hierarchical RBAC, Static Separation of Duty Relations, and Dynamic Separation of Duty Relations. Core RBAC defines a minimum collection of RBAC elements, element sets, and relations in order to completely achieve a Role-Based Access Control system. This includes user-role assignment and permission-role assignment relations, considered fundamental in any RBAC system. In addition, Core RBAC introduces the concept of role activation as part of a user's session within a computer system. Core RBAC is required in any RBAC system, but the other components are independent of each other and may be implemented separately. |
| | 5 | |
| | 6 | The Hierarchical RBAC component adds relations for supporting role hierarchies. A hierarchy is mathematically a partial order defining a seniority relation between roles, whereby senior roles acquire the permissions of their juniors and junior roles acquire users of their seniors. In addition, Hierarchical RBAC goes beyond simple user and permission role assignment by introducing the concept of a role's set of authorized users and authorized permissions. |
| | 7 | |
| | 8 | A third model component, Static Separation of Duty (SSD) Relations, adds exclusivity relations among roles with respect to user assignments. Because of the potential for inconsistencies with respect to static separation of duty relations and inheritance relations of a role hierarchy, the SSD relations model component defines relations in both the presence and absence of role hierarchies. |
| | 9 | |
| | 10 | The fourth model component, Dynamic Separation of Duty (DSD) Relations, defines exclusivity relations with respect to roles that are activated as part of a user's session. |
| | 11 | |
| | 12 | Each model component is defined by the following sub-components: |
| | 13 | * a set of basic element sets |
| | 14 | * a set of RBAC relations involving those element sets (containing subsets of Cartesian products denoting valid assignments) |
| | 15 | * a set of Mapping Functions, which yield instances of members from one element set for a given instance from another element set. |
| | 16 | |
| | 17 | It is important to note that the RBAC reference model defines a taxonomy of RBAC features that can be composed into a number of feature packages. Rather then attempting to define a complete set of RBAC features, this model focuses on providing a standard set of terms for defining the most salient features as represented in existing models and implemented in commercial proucts. |
