Access control is at the heart of every secure system. Whether you're building a document collaboration tool, a multi-tenant SaaS platform, or a government-grade secure system, choosing the right access control model is a decision that will shape your architecture for years to come.

This guide walks through six mainstream models — ACL, RBAC, ABAC, PBAC, DAC, and MAC — explaining what each one does well, where it falls short, and when to use it.

01 / ACL — Access Control List

ACL
Access Control List · 访问控制列表

The Whitelist Approach

Core Concept

Each resource carries an explicit list of who is allowed to access it. Think of it as a guest list taped to the door of a private event.

Analogy: A whitelist posted on a meeting room door — only listed individuals may enter.

Pros

  • Resource-level precision
  • Simple to implement

Cons

  • Fragmented, hard to manage at scale
  • No role inheritance or grouping
Best for: Document systems, collaboration platforms (Notion, Trello), any scenario where permissions are resource-specific.

02 / RBAC — Role-Based Access Control

RBAC
Role-Based Access Control · 基于角色的访问控制

The Organizational Approach

Core Concept

Permissions are assigned to roles; users inherit permissions by being assigned a role. This is the model most enterprise systems grow into.

Analogy: Employees gain access based on their job title — managers, staff, and guests each get a different set of keys.

Pros

  • Clean structure, easy to reason about
  • Easy to reuse and maintain

Cons

  • Limited fine-grained control
  • Not flexible for edge cases
Best for: Enterprise back-office systems, HR/ERP/CMS systems, any organization with stable role definitions.

03 / ABAC — Attribute-Based Access Control

ABAC
Attribute-Based Access Control · 基于属性的访问控制

The Context-Aware Approach

Core Concept

Access decisions are evaluated dynamically based on attributes of the user, the resource, and the environment. This enables fine-grained, context-sensitive authorization.

Analogy: Allow access if: department = Finance AND resource = Report AND time < 18:00.

Pros

  • Highly flexible and expressive
  • Dynamic, context-aware decisions

Cons

  • Complex to configure and reason about
  • Policies can be hard to test and debug
Best for: Multi-tenant SaaS platforms, conditional access systems, scenarios requiring dynamic, attribute-driven decisions.

04 / PBAC — Policy-Based Access Control

PBAC
Policy-Based Access Control · 基于策略的访问控制

The Centralized Policy Approach

Core Concept

Access control is governed by centrally managed, reusable policy rules — often written in a dedicated policy language. This enables auditability and consistent enforcement across systems.

Analogy: Like an organization's internal policy handbook — every action must be justified by a written rule.

Pros

  • Centralized, auditable control
  • Integrates well with OPA, Casbin, and other policy engines

Cons

  • High abstraction barrier
  • Hard for non-developers to maintain
Best for: Zero-trust architectures, multi-tenant systems, compliance platforms — anywhere centralized policy governance is required.

05 / DAC — Discretionary Access Control

DAC
Discretionary Access Control · 自主访问控制

The Owner-Driven Approach

Core Concept

The owner of a resource decides who can access it, at their own discretion. This is the model behind file permissions in operating systems and sharing features in collaboration tools.

Analogy: The file owner sets "who can open this file" — just like sharing a Google Doc with specific people.

Pros

  • Intuitive for users
  • Flexible and easy to grant access

Cons

  • No centralized policy enforcement
  • Risk of accidental over-exposure
Best for: File sharing systems, OS file permissions (Linux), any scenario where resource owners should control access.

06 / MAC — Mandatory Access Control

MAC
Mandatory Access Control · 强制访问控制

The Security-First Approach

Core Concept

The system enforces access based on security labels assigned to both users and resources — users cannot override these rules. This is the model used in high-security environments.

Analogy: A "Top Secret" document can only be accessed by people with the matching clearance level — no exceptions.

Pros

  • High security guarantees
  • Not dependent on user behavior

Cons

  • Inflexible by design
  • Unsuitable for most business applications
Best for: Military/government systems, financial core platforms — anywhere maximum security is the priority.

Quick Reference: Model Comparison

Model Control Method Granularity Flexibility Mgmt Complexity Recommended For
ACL Per-resource whitelist Fine Medium Low Docs & Collaboration
RBAC Role-based inheritance Medium Low Low Enterprise Systems
ABAC Attribute rule evaluation Very Fine High High SaaS Dynamic Authz
PBAC Centralized policy language Any Very High Very High Compliance / Zero-Trust
DAC Owner discretion Simple Low Low File Systems / Sharing
MAC Security label enforcement Strict tiers High High Gov / Military / Finance

Hybrid Patterns: Mixing Models in Practice

In real-world engineering, no single model fits all requirements. The most effective systems layer multiple models to balance structure, flexibility, and security.

ACL + RBAC

Role-based structure for most access, with fine-grained per-resource overrides via ACL. Common in document management and collaboration tools.

RBAC + ABAC

Roles define baseline permissions; attributes enforce dynamic, context-sensitive restrictions on top. Ideal for SaaS platforms with varying tenant rules.

PBAC + ABAC + RBAC

Enterprise-grade combination for large platforms, zero-trust architectures, or multi-tenant systems requiring full auditability and policy governance.

How to Choose: A Decision Guide

Still not sure which model fits your system? Answer these questions to narrow it down:

Are your user roles stable and clearly defined across the system? → Choose RBAC

Do different resources need different access rules (per-file, per-record)? → Choose ACL

Do you need dynamic, context-sensitive access (time, location, device)? → Choose ABAC

Do you need centralized, auditable policies for compliance or zero-trust? → Choose PBAC

Should individual resource owners control their own sharing and access? → Choose DAC

Is the highest security priority — even at the cost of flexibility? → Choose MAC


Access control is never one-size-fits-all. The best systems start with a clear understanding of their security requirements, user workflows, and growth trajectory — then pick the model (or combination of models) that fits. If you're designing a new system, take the time to map out your access patterns before writing a single line of authorization code. Your future self will thank you.