NISTRBAC
From Bandit-project.org
Contents |
National Institute of Standards and Technology - Role Based Access Control (NIST RBAC)
“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." ANSIINCITES359-204
RBAC Reference Model
The drawing above actually shows roles in a system more complex than NIST RBAC allows for by adding: policy associations, XACML Authorizations and Temporal Constraints. The roles calculator current charter is limited to user and role memberships/associations without considering off the AC (Access Control) portion of the acronym, or any of the additions to NIST RBAC shown in the drawing.
Core RBAC
"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.” ANSIINCITES359-204
Hierarchical RBAC
"Hierarchies are a natural means of structuring roles to reflect an organization’s lines of authority and responsibility. Role hierarchies define an inheritance relation among roles. Inheritance has been described in terms of permissions; i.e., r1 “inherits” role r2 if all privileges of r2 are also privileges of r1. For some distributed RBAC implementations, role permissions are not managed centrally, while the role hierarchies are. For these systems, role hierarchies are managed in terms of user containment relations: role r1 “contains” role r2 if all users authorized for r1 are also authorized for r2. Note, however, that user containment implies that a user of r1 has (at least) all the privileges of r2, while the permission inheritance for r1 and r2 does not imply anything about user assignment."
"This standard recognizes two types of role hierarchies—general role hierarchies and limited role hierarchies. General role hierarchies provide support for an arbitrary partial order to serve as the role hierarchy, to include the concept of multiple inheritances of permissions and user membership among roles. Limited role hierarchies impose restrictions resulting in a simpler tree structure (i.e., a role may have one or more immediate ascendants, but is restricted to a single immediate descendent)." ANSIINCITES359-204
Constrained RBAC
"Constrained RBAC adds Separation of Duty relations to the RBAC model. Separation of duty relations are used to enforce conflict of interest policies that organizations may employ to prevent users from exceeding a reasonable level of authority for their positions. As a security principle, separation of duty has long been recognized for its wide application in business, industry, and government. Its purpose is to ensure that failures of omission or commission within an organization are caused only as a result of collusion among individuals. To minimize the likelihood of collusion, individuals of different skills or divergent interests are assigned to separate tasks required in the performance of a business function. The motivation is to ensure that fraud and major errors cannot occur without deliberate collusion of multiple users."
Static Separation of Duty Relations
"Conflict of interest in a role-based system may arise as a result of a user gaining authorization for permissions associated with conflicting roles. One means of preventing this form of conflict of interest is through static separation of duty, that is, to enforce constraints on the assignment of users to roles. Static constraints can take on a wide variety of forms. A common example is that of Static Separation of Duty (SSD) that defines mutually disjoint user assignments with respect to sets of roles. Static constraints have also been shown to be a powerful means of implementing a number of other important Separation of Duty policies."
"The static constraints defined in this model are limited to those relations that that place restrictions on sets of roles and in particular on their ability to form UA relations. This means that if a user is assigned to one role, the user is prohibited from being a member of a second role. An SSD policy can be centrally specified and then uniformly imposed on specific roles. From a policy perspective, static constraint relations provides a powerful means of enforcing conflict of interest and other separation rules over sets of RBAC elements. Static constraints generally place restrictions on administrative operations that have the potential to undermine higher-level organizational Separation of Duty policies. RBAC models have defined SSD relations with respect to constraints on user-role assignments over pairs of roles (i.e., no user can be simultaneously assigned to both roles in SSD). Although real world examples of this SSD policy exist, this definition is overly restrictive in two important aspects. The first aspect being the size of the set of roles in the SSD and the second being the combination of roles in the set for which user assignment is restricted. In this model SSD is defined with two arguments—a role set that includes two or more roles and cardinality greater than one indicating a combination of roles that would constitute a violation of the SSD policy. For example, an organization may require that no one user may be assigned to three of the four roles that represent the purchasing function." ANSIINCITES359-204
Dynamic Separation of Duty Relations
"Static separation of duty relations reduce the number of potential permissions that can be made available to a user by placing constraints on the users that can be assigned to a set of roles. Dynamic Separation of duty (DSD) relations, like SSD relations, are intended to limit the permissions that are available to a user. However, DSD relations differ from SSD relations by the context in which these limitations are imposed. SSD relations define and place constraints on a user’s total permission space. This model component defines DSD properties that limit the availability of the permissions over a user’s permission space by placing constraints on the roles that can be activated within or across a user’s sessions. DSD properties provide extended support for the principle of least privilege in that each user has different levels of permission at different times, depending on the role being performed. These properties ensure that permissions do not persist beyond the time that they are required for performance of duty. This aspect of least privilege is often referred to as timely revocation of trust. Dynamic revocation of permissions can be a rather complex issue without the facilities of dynamic separation of duty, and as such it has been generally ignored in the past for reasons of expediency." ANSIINCITES359-204
RBAC System and Administrative Functional Specification
"The RBAC System and Administrative Functional Specification specifies the features that are required of an RBAC system. These features fall into three categories, administrative operations, administrative reviews, and system level functionality. The administrative operations define functions in terms of an administrative interface and an associated set of semantics that provide the capability to create, delete and maintain RBAC elements and relations (e.g., to create and delete user role assignments). The administrative review features define functions in terms of an administrative interface and an associated set of semantics that provide the capability to perform query operations on RBAC elements and relations. System level functionality defines features for the creation of user sessions to include role activation/deactivation, the enforcement of constraints on role activation, and for calculation of an access decision." ANSIINCITES359-204
NIST RBAC Desired Enhancements
Using a policy engine to compute role membership
Dimensionality of Roles