RBAC History, Terminologies & Standards

In the last few posts, we have been discussing about access control, specially Role Based Access Control. This access control is based on defining a set of rules and assigning a set of permissions and users to those rules. It is generally shortened to RBAC, which is generally pronounced as R-BACK. In this post we are going to discuss a little about the history and terminologies of RBAC, very briefly.

RBAC is a verb-oriented model which focuses on operations within a system and assigns rights on them by defining roles. These roles are then assigned to identities. A role is basically a semantic construct forming the basis of access control policy [Sandhu, Coyne, Feinstein, Youman]. For Windows world, Role can be a similar concept than group (specially for flat RBAC) but Role should be considered as a set of permissions. On the other hand, group should be considered as a set of users. Now this set of users can have permissions assigned to them. In that case, groups would behave like roles.

History of RBAC Research
Role Based Access Control (RBAC) was first formalized by Robert Kuhn and David Ferraiolo in 1992. In 2000, their model was integrated with Sandhu's framework, which was adopted as ANSI / INCITS standard in 2004 [NIST Reference]. In 2004, the standard received a ballott approval by International Committee for Information Technology Standards and adopted as INCITS 359-2004. In 2010, it was revised to incorporate features of Attribute based Access Control [ABAC].

Other useful reference: Sandhu, Farraiolo, Kuhn

RBAC Security Principles:
There are three RBAC security principles. They are least privileges, separation of duties and Data Abstraction. Here principles of least privilege is apparent, it recommends only those permissions should be assigned to a role which are required to perform the duties for the roles. Separation of duties is discussed later in this post, it is about activation of mutually exclusive roles. Data Abstraction suggests more abstract permissions and not read / write kind of permissions generally used by ACLs in operating system.

RBAC Components & Levels
RBAC can be divided into four levels. These levels are listed in the order of increasing functional capabilities. Each level adds exactly one new requirement to its lower level.

1. Flat RBAC / Core RBAC [RBAC₀: This is the lowest level of RBAC. This requires a many to many relationship between User and Roles, plus another many to many relationship between roles and permissions. The system must ensure that the user can use the permissions of multiple roles simultaneously. There should also be a user-role review process which allows to assign / remove any user from any role. This is also called RBAC₀


2. Hierarchical RBAC [RBAC₁]: This is the next level of RBAC. In addition to the requirements of flat RBAC, the system at this level should support hierarchical role models i.e. roles should be allowed to be defined in terms of other roles. In the role hierarchy, these roles can inherit the permissions of their parent role. This might also be an activation hierarchy where just using a senior role doesn't automatically use the permissions of a junior role unless specifically selected. The user-role review now include hierarchical roles as well. It must be made sure that there is no cyclic relationship.


3. Constrained RBAC [RBAC₂]: This level of RBAC enforces Separation of duties. This requires constraint in user - role assignment or activation of roles for a session. The system must enforce not using conflict of interest roles simultaneously. The conflict of interest might be taken care of by separation of duties amongst different roles. The separation of duties can be static or dynamic. In the static case, the separation of duties is taken care of roles assignment to the user. Any role which could cause a conflict of interest can't be assigned. In the case of Dynamic separation of duties (DSD), conflicting roles can be assigned to the user but the system must enforce that they can't be used simultaneously in the same session. These policies are inherited in the role hierarchies.
   
   Other constrained can be cardinality of roles which refers to the maximum number of users assigned to a role. Additionally, there can be constraint on pre-requesite role i.e. a user can be assigned a role only if it already has been assigned to some other specific role.
   
   The whole idea is to create sets SSD (Static Separation of Duties) and DSD (Dynamic Separation of Duties) sets and assign roles and roles hierarchies to it. For static separation of duties, a role cannot be part of another set once this has already been assigned to another set. For DSD, this enforcement takes place at runtime when the roles are being activated for a session.


4. Symmetric RBAC [RBAC₃]: This is the highest level of RBAC model. At this level, the system allows role - permission review. This review include the direct permissions assigned to the roles assigned to a user. This also include the permissions inherited from a junior role.

Note: Sandhu recommends separate admin roles and permissions which are separate (no inheritence) from regular roles and permissions. The admininstration can also have its respective ARBAC levels (0 - 3), (here A is Administrative).

Other RBAC Attributes
Standard NIST RBAC models don't put a constraint on the following RBAC attributes:

• Scalibility: The standard model doesn't put a constraint on the size of model. This can be in the sense of number of roles, number of users and permissions. This also doesn't include a role - permissions scalibility.


• Authentication: The standard model doesn't discuss authentication of user in the system. The standard doesn't either discuss how the users would be assigned to the roles.


• Negative Permissions: The permissions discussed in the model are positive permissions. Negative permissions are not considered.


• Nature of permissions: The standard model doesn't discuss the nature of permissions i.e if they should be fine grained or coarse grained.


• Administration and revocation: The model doesn't discuss how the users, roles and permissions are administered. Some example systems require a more administrative based centralized model. This can also be based on DAC (Discretionary Access Control) which allow the users to pass on the role permissions to other users.


• Role Engineering: There is no specification of how roles would be created and managed. This also doesn't provide any guideline how permissions are assigned to the roles. This should also include decommissioning of roles.


• Discretionary role activation: The standard model doesn't require role activation individually or a set of roles. The model just specifies the simultaneous use of multiple roles. The Level IV Separation of duties doesn't incorporate obligation constraints. Unlike this, the Level IV constraint prevents things from happening.


• Session Management: RBAC specifies sessions in core and constrained context. But how are these sessions created and managed? There is no reference about this in the original model and it is open to implementation.
  

Attribute Based Access Control [ABAC]
Original RBAC standard is not sufficient for dynamic attributes. These dynamic attributes might include time of day, market conditions, weather or any other dynamic condition which changes over time. It is very difficult to review ABAC system or how much is the risk exposure for a particular employee as the rules are dynamic in nature. The permissions to a user in a session would be the intersection of role-based permission rules and attribute-based permission rules. [Adding Attributes to RBAC [Weil, Coyne, Kuhn]]

Dynamic Parameterized Roles: Dynamic nature of the roles are important because RBAC enforces security on verbs. So users are allowed to perform some actions / operations but it is a matter of how much of these operations are they allowed to perform. This might depend on the time of day i.e. these operations are only allowed in a certain duration during the day.

Note: I have tried to summarize the discussion in the referenced papers. If there is anything wrong, I would be glad to correct it.