Data Protection and Security

   

V

Access Control

   

V.III

Role Based Access Control (RBAC)

   

   
 

Many organizations base access control decisions on the roles that individual users take on as part of the organization. They prefer to centrally control and maintain access rights that reflect the organization's protection guidelines. With RBAC, role-permission relationships can be predefined, which makes it simple to assign users to the predefined roles. The combination of users and permissions tend to change over time, the permissions associated with a role are more stable.

Note that the terms "group" and "role" do not have the same meaning. Group is a list of principals (subjects), while a role is a fixed set of access permissions that one or more principals may assume for a period of time using some defined procedure.

Example: In military, it is the role that matters rather than individuals. An example of a role is "the officer of the watch on a ship".

RBAC concept supports three well-known security principles:

  • Least privilege: Permissions for roles are assigned complying with this principle.
  • Separation of duties: For sensitive tasks, invocation of mutually exclusive roles are needed. For example in banking transfer over $10 million must be approved both by an employee with a rank of manager and a one with a rank of assistant acountant.
  • Data abstraction: Instead of only elementary access right such as read, write and execute, more abstract permissions such as cerdit and debit for an account can also be established.

A reference model for RBAC is depicted in the following figure. We briefly discuss the important points in this model below:

  1. Both user assignments and permission assignments are many-to-many.
  2. Users establish sessions during which they may activate a subset of roles they have. Each session is associated with a single user. By this way, the concept of session equates with the traditional notion of subject.
  3. Constraints are an important aspect of RBAC. An example of a constraint is that the same individual is not allowed to belong to two different roles at the same time. This constraint implements the separation of duties principle discussed above. Another example is the maximum number of users in a role. For instance only one user can have the role of a departmental chair.

For more information: Ravi S. Sandhu et al.: Role-Based Access Control Models. IEEE Computer 29(2): 38-47 (1996).

The concept of role has been known for a long time. However, until recently developers either hard-coded it in their application or as a custom middleware. Low maintenance costs and increased efficiency are among the key benefits of RBAC as a security strategy for midsize and large organizations which can be achieved only if it is integrated across all applications as a centralized system. Only this approach provides a global control process for managing IT assets while maintaining the desired level of security.

Next, we will explain two remaining important concepts in RBAC models.

 


Figure V.III-I

A simplified role based access control model. [click to enlarge]

V.III.I Q

[+] Question

[-] Question

Is RBAC a discretionary or mandatory access control?

   

   
       
 
«previous session [1] [2] [3] next session »
   
       
 
«proceed to previous section proceed to next section »
   chapter index