Mastering Access Control: From ACL to RBAC and Beyond

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 tries to edit an article, the system checks the ACL for that action. 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 a subject to grant its own permissions to other subjects, enabling permission delegation. Example: typical file‑system permissions in Linux, UNIX, and Windows NT. Drawback: control is scattered; a subject may unintentionally expose information because permissions are too broad.

MAC Model: Mandatory Access Control

MAC relies on a two‑way label verification: both subjects and objects carry security labels, and access is granted only when the labels match according to policy. Example: military ranks (general > colonel > major) correspond to document classification levels (top‑secret > secret > confidential); a major can only read confidential files. Drawback: overly strict, high implementation effort, and limited flexibility.

ABAC Model: Attribute‑Based Access Control

ABAC authorizes requests by dynamically evaluating a set of attributes—subject, object, environment, and operation. Attributes are typically grouped into four categories: 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: departments A and B share exam‑taking rights from 09:00‑11:00 and grading rights from 14:00‑17:00. Drawback: rule complexity makes it hard to understand relationships and difficult to implement, so it is rarely used in practice.

RBAC Model: Role‑Based Access Control

RBAC centers on assigning users to roles, where each role aggregates a set of permissions. The three core elements are users, roles, and permissions. Advantages include easier role division, flexible authorization, and fine‑grained control.

RBAC can be deepened into four variants: RBAC0, RBAC1, RBAC2, and RBAC3.

RBAC0

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

RBAC1

Introduces role hierarchy; child roles inherit all permissions of their parent role, similar to a tree structure.

RBAC2

Adds constraints such as mutually exclusive roles (e.g., a cashier cannot also be an auditor) and role cardinality limits (e.g., only one CEO role). These constraints tighten security and clarify responsibilities.

RBAC3

Combines the hierarchical features of RBAC1 with the constraint mechanisms of RBAC2, offering the most comprehensive RBAC variant.

Practical Application of RBAC in Real Systems

User Management

Users correspond to employees; their organization or business‑line hierarchy can be leveraged to group them. This approach yields clear structure, good scalability, and readability.

Role Management

Roles should be designed after deep understanding of business logic, often mirroring actual departmental positions. Best practices include automatic assignment of base roles on onboarding, temporary roles with expiration for external collaborators, virtual roles to aggregate ad‑hoc permissions, and whitelist/blacklist mechanisms for special cases.

Permission Management

Permissions are typically controlled on three dimensions: page/menu visibility, operation rights (CRUD on specific data), and data-level rights (row‑level and column‑level). For high‑security scenarios, backend checks must enforce data permissions in addition to front‑end UI hiding.

Additional RBAC Practices

Super Administrator : a hidden account with all system permissions, used only for initial setup; misuse poses a serious security risk.

Mutually Exclusive Roles : when adding a new role that conflicts with an existing one, the system should prompt the administrator to remove the conflicting role first.

Simplicity : keep the permission system as simple as possible; unnecessary roles and constraints lead to unmanageable complexity as the organization grows.

Unauthorized Access Page : provide a friendly “no permission” page instead of a generic 404 when a user attempts to access a restricted resource.