Mastering Access Control: 5 Core Permission Models Explained

Today we discuss permission system design and the five mainstream permission models.

ACL Model: Access Control List

Access Control List (ACL) is the earliest and most basic access control mechanism, operating 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; if present, editing is allowed.

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; a subject may unintentionally expose information due to overly broad rights.

MAC Model: Mandatory Access Control

MAC uses a bidirectional verification mechanism where both subjects and objects carry security labels, and access is granted only when the labels match according to policy.

Example: Military ranks (e.g., general > colonel > major) correspond to document classification levels (top secret > secret > confidential); access is allowed only when rank and classification align.

Drawback: Extremely strict, leading to high implementation effort and low flexibility.

ABAC Model: Attribute‑Based Access Control

ABAC authorizes access by evaluating dynamic attributes of subjects, objects, environment, and actions, offering fine‑grained and flexible control.

Four attribute categories:

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

Object attributes (e.g., a document)

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

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

Example: Departments A and B share a testing role in the morning and a grading role in the afternoon.

Drawback: Complex rules make implementation difficult; few systems adopt it.

RBAC Model: Role‑Based Access Control

RBAC links users to roles, and roles to permissions, simplifying management.

Three core elements:

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.

Users obtain permissions by being assigned appropriate roles, and roles can inherit permissions from other roles.

RBAC Deep Extensions

RBAC0 Model

Defines many‑to‑many relationships between users‑roles and roles‑permissions.

RBAC1 Model

Introduces role hierarchy, allowing child roles to inherit permissions from parent roles.

This hierarchy prevents permission gaps when moving users between hierarchical positions.

RBAC2 Model

Adds constraints such as mutually exclusive roles and role cardinality limits.

These constraints enhance security by ensuring clear separation of duties.

RBAC3 Model

Combines features of RBAC0, RBAC1, and RBAC2, providing a comprehensive role‑based framework.

Practical Application of RBAC in Real Systems

User Management

User management aligns with the organization’s structure, making it easy to map employees to system users.

Special attention is needed when organizational and business hierarchies differ; data sharing mechanisms must be considered.

Role Management

Roles should reflect real‑world job functions and be designed after thorough business analysis.

Roles are relatively stable; each role encapsulates a defined set of permissions.

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 access.

For high‑security scenarios, backend checks must complement frontend restrictions to prevent unauthorized data manipulation.

Additional Practices

Super Administrator : A hidden account with full system rights, used only for initial setup.

Mutually Exclusive Roles : Prevent assigning conflicting roles to the same user without prior revocation.

Simplicity : Keep the permission model as simple as possible to avoid future complexity.

No‑Permission Page : Provide a friendly “no access” page instead of a generic 404 error.