Welcome to the jGuard's wiki » jGuard Documentation » Which Access Control model is the best solution to manage security?

Which Access Control model is the best solution to manage security?

Last modified by RaffaelloPelagalli on 2006/12/29 01:11

Which Access Control model is the best solution to manage security?

jGuard uses an ABAC access control model.

Here is a list of the different 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 allows assignment of permissions to users which are part of the group of the owner, or other users. This access control is not very flexible for medium or large organization which have many users. This mechanism has the following issues: If the user quits the organization, many security operations are needed, to assign the same authorization to the new user; and this system assumes that the user is not malicious, because the user owns the resource, and can do whatever he wants with it, including granting access to 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 mechanism, 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 roles 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.

Attribute Based Access Control (ABAC)

ABAC permits to resolve access control decisions on role, and permissions like in the RBAC model, but also on user attributes. since jGuard 1.0.0, we permit to include in permissions (see contextual permissions) and roles(see dynamic role definition) some variables referencing user attributes.

Created by diabolo512 on 2006/02/09 14:34

jGuard team copyright 2004-2009