It is often to design a system where the owner do not want to reveal all their data to anyone or anonymous.

For example, bloggers want anonymous users be able to view their blog posts but they never want any other than editors be able to edit their blog posts. Furthermore, blog owner might want some one be able to edit but not able to change other high level blog setting. The owner also might lock some specific post for paid user. In multiple editors platform, standard editors should be able to edit only posts created by themselves.

In a chat application, system designer never want any user other than who are involved in the group can see the conversation's content.

These requirements are general called access control, or authorization.

Authentication vs Authorization

Developers usually are confused these 2 terms. What is the difference?

Authentication means authenticate your identity via provided identity (username, email, ...) and password (or token).

In the contrast of authorization, which means authorize/grant your privilege to execute some specific operations.

  • Authentication is to differentiate between anonymous and logged in (authenticated) users.
  • Authorization occurs after authentication passed.
  • Authorization differentiate authenticated users via their identity using access control


Before going to the main section of authorization, lets define some terminologies

  • Subject: an authorized user (can be anonymous)
  • Object: the object on which a subject want to apply an operation on
  • Permission: list of operations applied on the object

Given a subject who wants to apply an operation on an object, the access control system (privilege system) keeps the responsibility to determines whether the subject has the permission to apply an operation on the object.

Access control patterns

In software architecture, there are various types of access control patterns (check this wiki article): ABAC (attribute-based AC), DAC (discretionary AC), HBAC (history based AC), IBAC (identity based AC), MAC (mandatory AC) , OrBAC (Organization based AC), RBAC (role based AC), RAC, LBAC, CBAC (context based AC), ERBAC (Entity-Relationship BAC, or, Extended Role-BAC), SAC (semantic AC).

Two most observed patterns are Discretionary Access control (DAC) and Role-Based Access Control (RBAC). Mandatory Access Control (MAC) is also relatively common, but not as much as the 2 former.

Discretionary Access control (DAC)

DAC can be recognized easier when being referred with access control list (ACL), which is typically the first concept that people working with security think about. ACL contains a list of records, each record defines a specific access control rule. Each record in ACL is called Access-Control entry (ACE).

ACE contains 3 elements (x, y, z) (∈ Object × Subject × Permission), implies that subject x has permission y on object z.

Many OS implements file system permission control using ACL structure. In file system, subject can be individual user, group, object can be program, process, or files, permission can be read, write, execute.

Many relational database systems (SQL) have used ACL model in their administrator modules. In modern SQL implementations, ACLs also manage groups and inheritance in a hierarchy of groups.

Role-Based access control (RBAC)

RBAC is a access-control pattern which use roles and privileges to determine user permission. This pattern is at least powerful as MAC or DAC because it can implement either of them.

Compared to DAC, RBAC introduces 1 more entity called role. Permissions are no more directly assigned to subject, in RBAC, they are indirectly implied via role.

Each subject has multiple roles. One role has multiple permissions. In order to obtain a permission, a subject has to obtain at least one role which has the permission.

With the role concept, it becomes convenient to manipulate permission when an user has been added, changed.

The most basic RBAC model is called core RBAC.

In additional, RBAC may have role hierarchy, where a role inherits all permission from its sub roles. With the additional role hierarchy, RBAC model is called hierarchical RBAC.

To achieve separation of duties, RBAC defines constraints which determine opposing roles, in which an user can not have both 2 opposing roles. This model allows putting more complicated but useful constraint of separation of duties, such as disallowing the same user being able to both create a login account and to authorize the account creation. This type of RBAC is called constrained RBAC.

Wordpress user management is typical use case of RBAC. An wordpress user can be a anonymous, editor, or administrator user. The role-permission relationship is hard coded in the PHP source code.

AWS Resource-Based Policies is an example of ABAC.

Reference [6] gives remarkable comprehensive concept about RBAC from simple to sophisticated about RBAC variations (RBAC-0 RBAC-1, RBAC-2, RBAC-3), how RBAC is used to manage itself, RBAC's flexibility and power to implement many different variations of classical lattice-based mandatory access controls, a conceptual three-tier architecture for specification and enforcement, open issues in RBAC.


Note that there is no precise definition of DAC or RBAC, because they both are concept of designing a privilege system. In favor of comparability, the following comparison considers very a very pure implementation of both concepts. These comparison based on this stack exchange answer.

  • DAC is about personal permission while RBAC is group-level permission.
  • In DAC, the data owner set the permission, while in RBAC system owner defines role-permission relationship.
  • In DAC, ACL is typically dynamically attached to resource, while in RBAC, role-permission relationship is hard coded and subject-role relationship is defined dynamically.
  • In RBAC, subject is granted with role, and roles are fixed with permissions statically. While in DAC, permissions are changed at runtime per resource.
DAC should be seen as enumerating "who has access to my data", and RBAC defines "what can this user do"
  • DAC is considered more granular than RBAC, because it can set permission per resource.

Source list

Summary of the reference [6]

Role-based access control by Ravi S. Sandhu

At Laboratory for Information Security Technology, Information and Software Engineering Department, MS 4A4 George Mason University, Fairfax, VA 22030, USA.

  1. Role vs group

Group is just a group of members (subjects)

Role have both subjects and permissions.

2. RBAC96 models

RBAC-0: the base model, specifies minimum requirement for any system that fully supports RBAC
RBAC-1, RBAC-2 are advanced RBAC models, they both include RBAC-0 and an additional component.

RBAC-1 = RBAC-0 + role hierarchies
RBAC-2 = RBAC-0 + constraints
RBAC-3 = RBAC-1 + RBAC-2

This family of RBAC (0, 1, 2, 3) are so called RBAC96.

Relationship among RBAC96 models
Thee RBAC-3 model

3. RBAC-0

In RBAC-0, there are 3 entities: U (user), R (role), P (permission). U (user) is same as subject in this article, in this section I will follow the convention in the book (i.e. U).

RBAC-0 also includes UA (user assignment), PA (permission assignment), and S (session).

Definition 1 (from the book)
PA⊆P×R. a many-to-many permission to role assignment relation
UA⊆U×R, a many-to-many user to role assignment relation
user: S→U, a function ampping each session s_i to the single user user(s_i) (constant for the session's lifetime)
roles: S→2^R, a function mapping each session s_i to a set of roles roles(s_i)⊆{r | (user(s_i), r) ∈ UA}, whose value can change by time. This implies that session s_i has the permissions {p | (p, r)∈PA} for all role r ∈ roles(s_i).

One session maps one user to many roles, which semantically means that the session actives subset of roles that the user belongs to.
RBAC-0 does not allow changing user in a session but changing activated roles in the session is acceptable.

RBAC-0 requires that permission only apply to data and resources rather than the components of RBAC itself. These special RBAC-modification permissions are called administrative permissions, and is assumed that only a single security officer can change these components/permissions.

Users are allowed to create a session whose user is the user himself, and to activate some subset of user's roles. Roles active in a session can be changed after creation.
RBAC-0 does not specify whether a session be able to create another session. Thus, session must be directly created by the user.

4. RBAC-1

RBAC-1 introduces RH (role hierarchies).

Example of role hierarchies

RH must be partial order.

RBAC-1 definition

5. RBAC-2

RBAC-2 adds constraints to RBAC-0. There exist many types of constraint.
The most frequently mentioned constraint in the context of RBAC is mutually exclusive roles, which disallows some roles to appears in a same place.

It'd better to quote from the book.

Separation of duties
SBAC-2 definition

Another type of constraint is cardinality constraint limiting maximum number of members in a role. Prerequisite roles specify whereby a user can be assigned to role A only if the user is already a member of role B. For example, in file system, a file permission can be given to an user only when the user has same permission on the directory which keeps the file.

many types of constraint

6. ARBAC97 Administrative Models

ARBAC97 = RBAC + Administrative Model
Administrative model is the model to control the SBAC permission manipulation roles itself.

ARBAC illustration
ARBAC definition