Understanding Common Access Control Models: ACL, DAC, MAC, ABAC, and RBAC

Hello everyone, I am Chen Mou. The video tutorial "Spring Cloud Alibaba Practical Project" has been recorded, covering Alibaba middleware, OAuth2 micro‑service authentication, gray‑release, and distributed transactions. Click the link to subscribe to the Spring Cloud Alibaba video series.

Recently, the "Spring Cloud Alibaba Practical" series added OAuth2.0 and social login content, prompting questions about permission system design. This article answers those questions by introducing the design of permission systems and the five mainstream access control models.

Permission control can be understood as power restriction: different users have different rights, leading to different data visibility and operation capabilities within an application.

The five mainstream models are:

ACL Model : Access Control List

DAC Model : Discretionary Access Control

MAC Model : Mandatory Access Control

ABAC Model : Attribute‑Based Access Control

RBAC Model : Role‑Based Access Control

ACL Model: Access Control List

ACL is the earliest and most basic access control mechanism, based on objects. Each object has a list recording which subjects can perform which actions on it. Example: when user A wants to edit an article, the system checks the article's ACL for user A.

Drawback: When the number of subjects grows, configuration and maintenance become costly and error‑prone.

DAC Model: Discretionary Access Control

DAC extends ACL by allowing subjects to grant their own permissions to other subjects, enabling permission delegation.

Example: common in file systems such as Linux, UNIX, and Windows NT.

Drawback: Permissions are scattered; it is difficult to set uniform permissions for a group of files, and subjects may unintentionally leak information.

MAC Model: Mandatory Access Control

MAC uses a two‑way verification mechanism, often applied in highly classified environments like military or municipal security software.

Principle: both subjects and objects have security labels; access is granted only when the labels match.

Example: military ranks (general > colonel > major) correspond to document classification levels (top‑secret > secret > confidential); a major can only access secret documents.

Drawback: Too strict, leading to high implementation effort and lack of flexibility.

ABAC Model: Attribute‑Based Access Control

ABAC solves RBAC’s shortcomings by authorizing based on dynamic evaluation of attributes.

Attributes are typically divided into four categories:

Subject attributes (e.g., user age, gender)

Object attributes (e.g., an article)

Environment attributes (e.g., time, location, frequency)

Operation attributes (e.g., read, write)

Example: during 9:00‑11:00, departments A and B take an exam as candidates; from 14:00‑17:00, they grade papers.

Drawback: Rules are complex, hard to visualize, and difficult to implement, so ABAC is rarely used in practice.

RBAC Model: Role‑Based Access Control

RBAC ties users to roles, and roles to permissions. The three core elements are:

User : all accounts in the system

Role : a collection of permissions (e.g., admin, developer, auditor)

Permission : specific actions such as menu access or CRUD operations

In RBAC, permissions are associated with roles; users acquire permissions by being assigned to appropriate roles.

Advantages: simplifies role division, provides flexible authorization, and supports fine‑grained permission granularity.

RBAC Deep Extensions

RBAC can be divided into four levels: RBAC0, RBAC1, RBAC2, and RBAC3. Most companies use RBAC0, which defines the basic many‑to‑many relationships between users‑roles and roles‑permissions.

1. RBAC0 Model

Users ↔ Roles (many‑to‑many) and Roles ↔ Permissions (many‑to‑many).

Diagram:

2. RBAC1 Model

Adds role hierarchy: child roles inherit permissions from parent roles, reducing configuration effort and preventing permission gaps.

3. RBAC2 Model

Introduces constraints such as mutually exclusive roles (e.g., a cashier cannot also be an auditor) and role cardinality limits (e.g., only a limited number of users can hold the CEO role).

4. RBAC3 Model

Combines features of RBAC1 and RBAC2, providing a comprehensive model.

Practical Application of RBAC in Real Systems

RBAC consists of three main management areas: user management, role management, and permission management.

1. User Management

Users correspond to employees; organizational structures can be used to group users.

Note: Real‑world organization structures may differ from company departments, requiring data‑sharing mechanisms.

2. Role Management

Roles should reflect actual business functions and may include automatic base roles, temporary roles with expiration, virtual roles for special permissions, and whitelist/blacklist mechanisms.

Automatic Base Roles

When an employee joins a department, their account automatically receives the department's base role and permissions.

Temporary Roles

External collaborators receive temporary roles with defined expiration to prevent lingering access.

Virtual Roles

Virtual roles aggregate permissions needed for special tasks without altering the underlying role hierarchy.

Whitelist / Blacklist

Whitelist grants specific users extra privileges beyond their role; blacklist restricts compromised users from critical permissions while allowing basic access.

3. Permission Management

Permissions are enforced at three levels:

Page/Menu permissions – hide UI elements for unauthorized users.

Operation permissions – control CRUD capabilities on data.

Data permissions – restrict row‑level and column‑level data access.

For high‑security requirements, server‑side checks must complement front‑end UI restrictions to prevent unauthorized data manipulation.

Row and Column Permissions

Row permissions control the number of records a user can see; column permissions control which fields of a record are visible.

Additional Practical Details in User Management System Design

1. Super Administrator

The super‑admin account configures the system and should be hidden after initial setup; it possesses all permissions and must be tightly controlled.

2. Handling Mutually Exclusive Roles

If a new role conflicts with an existing one, the system should prompt the administrator to remove the conflicting role before adding the new one.

3. Keep Permission Design Simple

Start with a clear, minimal design; unnecessary roles and complex logic lead to unmanageable permission sprawl as the business grows.

4. Unauthorized Access Prompt Page

Provide a friendly "no permission" page instead of a generic 404 when a user attempts to access a resource they lack rights for.