Mastering Access Control: 5 Core Permission Models Explained

ACL Model: Access Control List

ACL is the earliest and simplest access‑control mechanism, based on objects. Each object maintains a list of subjects that are allowed to perform specific actions. Example: when user A tries to edit an article, the system checks the ACL for that action. Drawback: configuration and maintenance become costly and error‑prone as the number of subjects grows.

DAC Model: Discretionary Access Control

DAC extends ACL by allowing subjects to grant their own permissions to other subjects, enabling permission delegation. Example: file systems in Linux, UNIX, and Windows NT support DAC. Drawback: permissions become scattered, making it hard to apply uniform policies and increasing the risk of accidental data leakage.

MAC Model: Mandatory Access Control

MAC enforces a two‑way verification using security labels on both subjects and objects. Example: military ranks (general > colonel > major) correspond to document classification levels (top secret > secret > confidential); access is granted only when the subject’s label matches the object’s label. Drawback: the model is overly strict, requiring extensive implementation effort and offering little flexibility.

ABAC Model: Attribute‑Based Access Control

ABAC authorizes access by dynamically evaluating one or more attributes of the subject, object, environment, or operation. Typical attribute categories are subject attributes (e.g., age, gender), object attributes (e.g., document type), environment attributes (e.g., time window), and operation attributes (e.g., read/write). Example: departments A and B can take an exam together in the morning and grade papers in the afternoon. Drawback: rule complexity makes the model difficult to implement and it is rarely adopted in practice.

RBAC Model: Role‑Based Access Control

RBAC associates permissions with roles, and users acquire permissions by being assigned to roles. The three core elements are users, roles (collections of permissions), and permissions (menus, buttons, CRUD actions). Advantages include easier role‑centric management and fine‑grained authorization.

RBAC Extensions

RBAC0 : basic many‑to‑many relationships between users‑roles and roles‑permissions.

RBAC1 : adds role hierarchy (inheritance), allowing child roles to inherit all permissions of parent roles.

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

RBAC3 : combines the features of RBAC1 and RBAC2.

Practical Application of RBAC

User Management

Map users to the organization’s department or business‑line structure; consider data‑sharing mechanisms when organizational and business hierarchies differ.

Role Management

Design roles based on real job functions, support automatic base‑role assignment for new hires, temporary roles with expiration, virtual roles that aggregate ad‑hoc permissions, and whitelist/blacklist handling for special cases.

Permission Management

Three dimensions: page/menu permissions (hide UI elements for unauthorized users), operation permissions (CRUD rights on specific data), and data permissions (row‑level and column‑level access). High‑security scenarios require backend enforcement to prevent unauthorized data manipulation.