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

Hello everyone, I am Chen. My video tutorial series "Spring Cloud Alibaba Practical Project" has been completed, covering Alibaba middleware, OAuth2 micro‑service authentication, gray‑release, and distributed transactions.

In response to recent questions about OAuth2.0 and social login, this article introduces the design of permission systems and the five mainstream access‑control models.

Permission control can be understood as the restriction of power: different users have different data and operation permissions within an application.

ACL Model: Access Control List

ACL is the earliest and most basic access‑control mechanism, based on objects. Each object maintains a list of subjects and the actions they are allowed to perform.

Example: when user A wants to edit an article, the system checks whether A appears in the article's edit‑ACL. If present, editing is allowed.

Drawback: when the number of subjects grows large, 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 propagation.

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

Drawback: permission control becomes scattered; a subject may unintentionally expose sensitive data.

MAC Model: Mandatory Access Control

MAC enforces a two‑way verification mechanism, commonly used in highly classified environments (e.g., military, municipal security).

Principle: both subject and object carry security labels; access is granted only when the labels match according to predefined rules.

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

Drawback: overly strict control leads to high implementation effort and low flexibility.

ABAC Model: Attribute‑Based Access Control

ABAC evaluates dynamic attributes to decide authorization, offering fine‑grained and flexible control.

Four attribute categories:

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

Object attributes (e.g., a specific article)

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

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

Example: during 09:00‑11:00 two departments take an exam as candidates; from 14:00‑17:00 they grade papers.

Drawback: rule complexity makes implementation difficult; adoption is still limited.

RBAC Model: Role‑Based Access Control

RBAC ties permissions to roles; users acquire permissions by being assigned to roles.

Three core elements:

User: all accounts in the system

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

Permission: specific menu items, buttons, or CRUD operations on data

Roles simplify permission management, support inheritance, and enable easy reassignment.

RBAC Deep Extensions

RBAC can be refined into four levels:

RBAC0 – basic many‑to‑many user‑role and role‑permission relationships

RBAC1 – adds role hierarchy (inheritance)

RBAC2 – introduces constraints such as mutually exclusive roles and role cardinality limits

RBAC3 – combines RBAC1 and RBAC2 features

Most companies use RBAC0; higher levels are applied when additional constraints are needed.

RBAC0 Model

Illustrates the many‑to‑many relationship between users, roles, and permissions.

RBAC1 Model

Introduces role hierarchy, allowing child roles to inherit all permissions of their parent role.

RBAC2 Model

Adds 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 may hold the CEO role).

RBAC3 Model

Combines the features of RBAC1 and RBAC2, providing both hierarchy and constraints.

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; their organizational structure can be used to build the user management system.

Special attention: business organization may differ from department structure, requiring data‑sharing mechanisms.

2. Role Management

Roles should be designed after understanding company and business architecture, often mirroring real‑world department roles.

Automatic Base Role Assignment

When a new employee joins a department, their account is automatically added to the department's base role, granting baseline permissions.

Temporary Roles and Expiration

External collaborators receive temporary roles with defined expiration times to avoid lingering privileged accounts.

Virtual Roles

Virtual roles aggregate permissions that cross existing role hierarchies, allowing special‑case access without altering the core role structure.

Whitelist / Blacklist

Whitelist grants specific users extra privileges beyond their role; blacklist restricts users who have lost trust while keeping their accounts active for basic access.

3. Permission Management

Permissions are typically divided into page/menu permissions, operation permissions, and data permissions.

Page/Menu Permissions

Hide menu items or pages for users lacking the required permission.

Operation Permissions

Control CRUD capabilities on the same data set (e.g., read‑only vs. edit).

Data Permissions

Enforce row‑level and column‑level restrictions on the backend; unauthorized attempts are logged and blocked.

Row/Column Permission Control

Row permissions limit the number of records visible; column permissions limit which fields of a record are visible.

Additional Practical Details in User‑Management Permission Design

Super Administrator

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

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.

Simplicity and Clarity

Design the permission system with a clear, minimal structure to avoid unmanageable complexity as the business grows.

Unauthorized Access Prompt Page

Instead of a generic 404, provide a friendly "no permission" page when a user attempts to access a restricted resource.

Conclusion

All articles are carefully prepared; three series have been compiled into PDFs, which can be obtained by following the "Java Backend Interviewer" public account and replying with the appropriate keywords.

If you found this article helpful, please like, view, share, and bookmark—it fuels my continued effort.