Pattern-Oriented Software Architecture - Access control pattern

Sang

Sep 30, 2019 • 7 min read

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

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

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

These requirements are generally called access control or authorization.

Authentication vs Authorization

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

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

In contrast to 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 is passed.
Authorization differentiate authenticated users via their identity using access control

Terminology

Before going to the main section of authorization, let's 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 determine 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).

The 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 formers.

Discretionary Access control (DAC)

DAC can be recognized easier when being referred with an 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), which implies that subject x has permission y on object z.

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

Many relational database systems (SQL) have used the 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 an access-control pattern that uses 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 the subject, in RBAC, they are indirectly implied via role.

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

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

The most basic RBAC model is called core RBAC.

In addition, RBAC may have a role hierarchy, where a role inherits all permission from its sub-roles. With the additional role hierarchy, the RBAC model is called hierarchical RBAC. For example, the admin role includes all permissions assigned to the moderator role without explicitly declaring them.

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

WordPress user management is a typical use-case of (hierarchical )RBAC. A WordPress user can be an anonymous, editor, or administrator user. The role-permission relationship is hardcoded in the PHP source code.

AWS Resource-Based Policy 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.

DAC vs RBAC

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

DAC is about personal permission while RBAC is group-level permission.
In DAC, the data owner sets the permission, while in the RBAC system owner defines the role-permission relationship.
In DAC, ACL is typically dynamically attached to a resource, while in RBAC, the role-permission relationship is hardcoded and the subject-role relationship is defined dynamically.
In RBAC, the subject is granted with roles, 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.

Role vs group

Group is just a group of members (subjects)

The role has both subjects and permissions.

2. RBAC96 models

RBAC-0: the base model, specifies a 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) is the so-called RBAC96.

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. 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 mapping 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 applies to data and resources rather than the components of RBAC itself. These special RBAC-modification permissions are called administrative permissions and are 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 the 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, a session must be directly created by the user.

4. RBAC-1

RBAC-1 introduces RH (role hierarchies).

RH must be a partial order.

5. RBAC-2

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

It'd better quote from the book.

Another type of constraint is cardinality constraint limiting the 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 the file system, file permission can be given to a user only when the user has the same permission on the directory which keeps the file.