Welcome to the jGuard's wiki » 全体像 » Why Role Based Acces Control design(RBAC) is the best solution to manage security?

Why Role Based Acces Control design(RBAC) is the best solution to manage security?

Last modified by RaffaelloPelagalli on 2006/01/13 05:39

Why Role Based Acces Control design(RBAC) is the best solution to manage security?

here are listed differents Access Control Models:

Discretionary Access Control (DAC)

the main disadvantages are:

  • loss of flexibility
  • security is discretionary, not central
according to the Computer Security Division CSRC(Computer Security resource center) of the NIST(US),~~ DAC is used to control access by restricting a subject's access to an object. It is generally used to limit a user's access to a file.

In this type of access control it is the owner of the file who controls other users' accesses to the file.~~ this type of Access Control is generally used in UNIX systems. this mechanism can be used with the help of Access Control Lists (ACL), which permits to assign permissions to users which are part of the group of the owner, or others users. this access control is not very flexible for medium or large organization which have got many users. this mechanism has got the issue to rely on the user: if the user quits the organization, many security operations are needed, to assign to the new user, the same autorizations;and this system implies that the user must not be malicious, because the user owns the resource, and can do whatever he wants with it, and grant access to it to everyone. it can be a big security hole.

this mechanism is not suitable for an advanced security system.

to reflect these conclusions,and to prove that UNIX systems are not all boundto this old mechanism,you can point to:

  • the Solaris RBAC system introduced since solaris 8 (Solaris is a UNIX system shipped by SUN)
  • the gr-security security system for linux which also add RBAC features to the Linux kernel

Mandatory Access Control (MAC)

In Mandatory Access Control (MAC) models,Subjects(users) receive a clearance label and objects receive a classification label, also referred to as security levels.

no users can do operations on objects that are not permitted by the administrator which has configured the system. this system remove the discretionary aspect of the DAC model, to centrally control operations on objects made by users. But this system has got the disadvantage to not be flexible:

access rights are defined for each users;this mecahnism implies many administrative operations, when by example a user replace another one to a function in the organization.

Role Based Access Control (RBAC)

many informations comes from this RBAC draft provided by the NIST.

RBAC features are divided into 4 components.


  • relations between users, roles, permissions
the main principle of RBAC, is that users are assigned to roles(principals),permissions are assigned to roles, and acquires permissions by being members of roles. RBAC has go a great flexibility: user-role and permission-role relations are many-to-many, i.e a user can have many roles, and a role can be assigned to many users; and a permission an be assigned to many roles, and a role can have many permissions.

  • administrative functions
RBAC implies for administration tasks, to provide the way to know which users has got a specific role, and which roles has got a user.the same administrative function can be done between roles and permissions.

  • user sessions
core RBAC includes the concept of user sessions, which permit activation and deactivation of roles owned by users.

  • user and multiple roles
a user (which owns multiples roles) can be able to simultaneously exercise permissions of multiple roles. some security products handle multiples roles or groups in their mecahnism, but cannot exercise permissions of multiples roles at the same time!
  • centrally administering security
  • Least Privilege

hierarchical RBAC

RBAC recognises two types of hierarchies:

  • general hierarchy with support of multiple inheritance
  • limited hierarchy without support of multiple inheritance

Static separation of duty (SSOD)

This principle permits to avoid conflict of interest. it consists of constraints added to the user-role assignement, which prevents some role to be added to users which have got some others roles.The standard only specifies constraints on roles, but it can be useful to put constraint on permissions, or operations on protected ressources.

Dynamic separation of duty (DSOD)

Dynamic separation of Duty is an extension because it implies a separation of duty across the user's session.

Created by Masa Naka on 2006/01/13 05:39

jGuard team copyright 2004-2009