Skip to main content

In-depth Understanding of Authorization Models： RBAC, ABAC, ACL Permission Control Explained

[email protected]9/23/25...About 4 minDevelopment SkillsRBACABACACLPermission ControlAccess ControlSecurity ArchitectureAuthorization ModelsPermission Management

Deep Dive into Authorization Models: RBAC, ABAC, ACL

In modern software systems, Access Control is a core component of security architecture. It determines who can access what resources under what conditions. This article will delve into the three most common authorization models:

Three Common Authorization Models
Three Common Authorization Models

📋 Table of Contents

🔐 Overview of Three Mainstream Authorization Models

  • Role-Based Access Control (RBAC): Indirectly assigns permissions through roles
  • Attribute-Based Access Control (ABAC): Fine-grained control based on user, resource, and environmental attributes
  • Access Control List (ACL): Maintains permission lists directly at the resource level

These three models are not mutually exclusive in actual systems but are chosen or combined according to business complexity, security requirements, organizational structure, etc. Let's analyze them one by one.

One、RBAC: Role-Based Access Control

Basic Idea

The core concept of RBAC is:
Users do not directly bind with permissions but obtain permissions indirectly through roles (Role).

  • User → Role → Permission

For example:

  • Alice is assigned the Maintainer role
  • The Maintainer role has permissions to merge code, push code, and manage issues

When Alice requests "merge PR", the system only needs to determine if she has the Maintainer role.

Features

  • Advantages:

    • Simple permission management (only need to maintain role → permission mapping)
    • Suitable for stable organizational structures (such as internal enterprise systems)

  • Disadvantages:

    • Lack of flexibility (cannot judge based on dynamic context, such as time and location)

Implementation Approach

In the application layer, you can design the following data tables:

  • users: User information
  • roles: Role definitions
  • permissions: Permission definitions
  • user_role: User-Role mapping
  • role_permission: Role-Permission mapping

When a request enters the system:

  1. Parse user identity (JWT, OAuth Token, Session)
  2. Find the roles of this user
  3. Obtain the permission set corresponding to the role
  4. Determine if the requested operation is in the permission set

Two、ABAC: Attribute-Based Access Control

Basic Idea

ABAC extends access control to attribute level (Attributes), not just users and roles but also includes resource attributes, environmental attributes, action attributes.

For example:

  • User Attributes: department, position, security clearance
  • Resource Attributes: document classification, file owner
  • Environmental Attributes: access time, location, IP range

Access control is determined by a policy engine (Policy Engine), with common policy languages such as XACML.

Example Policy:

ALLOW IF
  user.department == "Finance"
  AND user.clearance == "Confidential"
  AND resource.classification == "Confidential"
  AND environment.time ∈ business_hours
  AND environment.ip ∈ corporate_range

Features

  • Advantages:

    • High flexibility, can achieve fine-grained permission control
    • Suitable for complex scenarios across departments and systems (such as multi-tenant SaaS)

  • Disadvantages:

    • Complex policy design and maintenance
    • Some impact on system performance

Implementation Approach

Common ABAC implementation steps:

  1. Collect Attributes

    • User attributes: obtained through identity authentication system (IdP)
    • Resource attributes: read from resource metadata
    • Environmental attributes: obtained from runtime context (IP, time, device information)

  2. Define Policies

    • Use policy language (such as JSON/YAML/XACML)
    • Store in policy repository

  3. Policy Evaluation

    • Request enters the system → submitted to policy engine
    • Engine evaluates based on attributes + policies → returns Allow/Deny

Typical implementation: OPA (Open Policy Agent) is a commonly used ABAC solution.

Three、ACL: Access Control List

Basic Idea

ACL maintains an access control list directly at the resource level, with each resource corresponding to a permission table.

For example:

Budget.xlsx ACL:
  alice@corp → Edit
  finance-team → Edit
  evan@corp → Edit
  guest@corp → View

When a user requests access, the system will:

  1. Query the ACL corresponding to the resource
  2. Check if the user is in the ACL (or in a group within the ACL)
  3. Make a decision based on permissions (View/Edit/Delete)

Features

  • Advantages:

    • Finest granularity, can be down to individual files or fields
    • Simple and intuitive implementation

  • Disadvantages:

    • Difficult to manage when resource numbers are large
    • Not suitable for large-scale enterprise environments

Implementation Approach

In databases or storage systems, common practices include:

  • Storing ACL lists (JSON/relational tables) for each resource
  • When a request is made, first retrieve the ACL and then determine if the user matches

ACLs are widely used in cloud storage services such as Google Drive and S3 Bucket Policy.

Comparison Analysis

ModelControl GranularityManagement DifficultyFlexibilityTypical Application
RBACModerate (role-based)LowAverageInternal enterprise systems, GitHub permissions
ABACHigh (attribute-based)HighExtremely highMulti-tenant SaaS, financial systems
ACLHighest (resource-based)MediumHigherFile systems, cloud storage

Combination Strategies in Practical Applications

In real-world systems, a single model is often insufficient to meet requirements. Common combination strategies include:

  • RBAC + ACL: First control broad permissions through roles, then refine with ACL.
  • RBAC + ABAC: Determine role permissions first, then use attributes for detailed judgments (e.g., administrators can only access production systems during working hours).
  • ABAC + ACL: Define basic access permissions with ACL, and enhance security dynamically with ABAC policies.

Summary

  • RBAC is suitable for systems with clear organization and relatively stable permissions
  • ABAC is suitable for complex systems requiring dynamic and fine-grained control
  • ACL is suitable for resource-level management, especially in file and document scenarios

When designing a permission system, consider business requirements, team size, compliance needs, and choose appropriate models or combinations to achieve balance between security, maintainability, and performance.

📖 Frequently Asked Questions

Q: How to choose the appropriate authorization model?

A: Choosing an authorization model requires considering:

  • System Complexity: Simple systems can use RBAC, complex multi-tenant systems recommend ABAC
  • Organizational Structure: Clear hierarchical organizations suit RBAC, flat organizations may consider ACL
  • Compliance Requirements: Financial and healthcare industries typically require the fine-grained control of ABAC
  • Performance Requirements: RBAC performs best in high concurrency scenarios

Q: Can these three models be used simultaneously?

A: Yes! In fact, many enterprise-level systems adopt hybrid modes:

  • RBAC handles basic permission allocation
  • ABAC handles dynamic policies (such as time and location restrictions)
  • ACL handles fine-grained permissions for special resources

Q: What is OPA (Open Policy Agent)?

A: OPA is an open-source policy engine mainly used to implement the ABAC model. It provides a unified policy language (Rego) and high-performance policy evaluation engines, widely applied in Kubernetes, microservices, and other cloud-native environments.

💡 Tip: The design of permission systems should follow the principle of least privilege (Principle of Least Privilege), where users should only have the minimum set of permissions necessary to perform their tasks.