Designing Permission Systems: Overview of ACL, DAC, MAC, ABAC, and RBAC Models

Permission control can be understood as the restriction of authority: different users have different data visibility and operation capabilities based on the permissions they possess. In an application system, this translates to varying data and operation permissions for each user.

ACL Model: Access Control List

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: before editing an article, the system checks whether user A appears in the article's edit ACL. Drawback: when the number of subjects grows large, configuration and maintenance become costly and error‑prone.

DAC Model: Discretionary Access Control

Discretionary Access Control (DAC) extends ACL by allowing subjects to grant their own permissions to other subjects, enabling permission delegation. Example: most file systems (Linux, UNIX, Windows NT) support DAC. Drawback: permissions become scattered, making it hard to apply uniform policies, and excessive privileges may lead to accidental data leakage.

MAC Model: Mandatory Access Control

Mandatory Access Control (MAC) enforces a two‑way verification mechanism, commonly used in highly classified environments such as military or government systems. Each subject and object carries a security label; access is granted only when the subject’s label dominates the object’s label. Example: a lieutenant can only access documents classified as "secret". Drawback: the model is overly strict, resulting in high implementation effort and limited flexibility.

ABAC Model: Attribute‑Based Access Control

Attribute‑Based Access Control (ABAC) evaluates dynamic attributes of subjects, objects, environment, and actions to make authorization decisions, offering fine‑grained and flexible control. Attributes are typically categorized as subject attributes (e.g., age, gender), object attributes (e.g., document type), environment attributes (e.g., time, location), and operation attributes (e.g., read, write). Example: two departments share a testing environment only during specific time windows. Drawback: rule complexity makes the model difficult to implement and therefore less commonly adopted.

RBAC Model: Role‑Based Access Control

Role‑Based Access Control (RBAC) centers on the relationship between users, roles, and permissions. Users are assigned roles; each role aggregates a set of permissions (menus, buttons, CRUD operations). RBAC simplifies permission management, supports role inheritance, and enables minimal‑granularity authorization.

RBAC consists of three core elements:

User: all accounts in the system.

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

Permission: specific access rights such as menu visibility, button actions, or data operations.

In RBAC, permissions are linked to roles, and users acquire permissions by becoming members of appropriate roles. Roles can be hierarchical, and permissions can be added or revoked as business needs evolve.

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, allowing child roles to inherit parent permissions.

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

RBAC3 – combines RBAC1 and RBAC2 features.

Most companies adopt RBAC0, while the higher levels provide additional governance for complex environments.

Practical Application of RBAC in Systems

RBAC permission management comprises three parts: user management, role management, and permission management.

User Management

Users correspond to employees; their organization hierarchy can be leveraged to structure user management. Special attention is needed when the business structure differs from the corporate hierarchy, requiring data‑sharing mechanisms.

Role Management

Roles should reflect real‑world job functions and be designed after thorough understanding of business logic. Roles are generally stable; each role has a clear set of permissions and constraints.

Automatic assignment of base roles upon employee onboarding.

Temporary roles with expiration for external collaborators.

Virtual roles that aggregate ad‑hoc permissions without altering the underlying role hierarchy.

Whitelist and blacklist mechanisms to grant exceptional privileges or restrict compromised accounts.

Permission Management

Permissions are typically divided into three dimensions:

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

Operation permissions – control CRUD capabilities on specific data sets.

Data permissions – row‑level and column‑level restrictions, often driven by organizational rules.

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

Additional Design Practices

Super Administrator: a hidden account with full system rights, used only for initial configuration.

Handling mutually exclusive roles: prevent assignment of conflicting roles without prior revocation.

Keep the permission system simple and clear to avoid unmanageable complexity as the organization grows.

Provide a "no‑access" prompt page instead of a generic 404 to improve user experience.

Overall, a well‑designed permission system balances security, flexibility, and maintainability by choosing appropriate models, defining clear role hierarchies, and applying granular data controls.