Access control models compared

An access control model is a way of expressing and deciding who may do what to which resource. Models differ in where the rules live, who can change them, and what questions they answer easily. Most real systems combine several.

The models at a glance

Discretionary access control (DAC)

The owner of a resource decides who else can access it. File-system permissions and document sharing (“share with Maya, can edit”) are DAC.

• Advantages: intuitive, flexible, no central bottleneck.
• Drawbacks: access sprawls, owners make inconsistent decisions, hard to enforce organization-wide rules.
• Use cases: collaboration tools, personal files, small teams.

Mandatory access control (MAC)

A central policy assigns labels such as Confidential or Secret to data and clearances to subjects. Rules such as Bell–LaPadula’s “no read up, no write down” protect confidentiality; Biba protects integrity. Users cannot share beyond what the labels allow.

• Advantages: strong, non-bypassable guarantees.
• Drawbacks: rigid, administrative overhead, poor fit for dynamic collaboration.
• Use cases: military and government classification, operating-system hardening (SELinux, AppArmor), multi-level secure systems.

ACLs and capabilities

These are two ways to store the same access matrix. An ACL is stored with the object (“who can access this file?”). A capability is held by the subject (“what can this token access?”).

• ACLs make “who can access X?” easy and “what can Maya access?” hard.
• Capabilities make delegation easy and revocation hard. OAuth access tokens behave like capabilities: whoever holds one can use it, which is why sender-constrained tokens and short lifetimes matter.

Role-based access control (RBAC)

Permissions are assigned to roles, and roles to subjects. The NIST/ANSI model defines four levels: flat (core), hierarchical (roles inherit from others), constrained (separation-of-duty rules), and symmetric (permission–role review).

• Advantages: easy to understand, review, and audit; maps to job functions; widely supported.
• Drawbacks: role explosion when access depends on context such as region, amount, or ownership; coarse-grained.
• Use cases: enterprise applications, workforce access, administrative consoles.

See RBAC, ABAC, and relationships and roles, groups, and entitlements.

Attribute-based access control (ABAC)

Policies evaluate attributes: “allow read if user.department == resource.department and time is within business hours”.

• Advantages: fine-grained, context-aware, fewer roles, expresses rules directly.
• Drawbacks: depends on attribute quality and freshness; answering “who can access X?” requires evaluating policies over all users; harder to explain.
• Use cases: regulated data, data classification, context-dependent access, multi-tenant rules.

Relationship-based access control (ReBAC)

Access follows from relationships: Maya can edit a document because she is an editor of the folder that contains it. Google’s Zanzibar paper popularized a scalable design based on relationship tuples (document:readme#editor@user:maya) and a schema that defines how relations compose.

• Advantages: natural for sharing, hierarchies, and ownership; answers both “can Maya edit X?” and “who can edit X?”; scales to very large datasets.
• Drawbacks: requires synchronizing relationship data into the authorization system; consistency and latency need care; modeling takes practice.
• Use cases: collaboration and document sharing, SaaS with organizations and teams, nested resources.

Policy-based access control (PBAC)

PBAC is less a distinct model than an architecture: authorization is externalized into policies managed as code and evaluated by a decision engine. The policies may use roles, attributes, and relationships. See policy engines and policy as code.

Next Generation Access Control (NGAC)

NGAC, developed at NIST, represents users, objects, attributes, and policy classes as a graph with assignments and prohibitions. It aims to express RBAC, ABAC, and MAC policies in one framework, with efficient review queries.

Choosing and combining

A common combination is RBAC for coarse application access, ReBAC for resource sharing, and ABAC conditions for context such as amount limits or device posture.

Implementations

The following are examples, not endorsements; check the official documentation for current capabilities.

References

• NIST RBAC project.
• NIST SP 800-162: Guide to ABAC.
• NIST SP 800-192: Verification and Test Methods for Access Control Policies/Models.
• Zanzibar: Google’s Consistent, Global Authorization System.
• OWASP Authorization Cheat Sheet.