AuthZ models¶

A Guide to Modern Authorization Models: RBAC, ABAC, ReBAC, and PBAC¶

Authorization (Authz) is the process of determining what an authenticated user is permitted to do within a system. It answers the question, “Now that we know who you are, what are you allowed to access?” As applications have grown in complexity, so have the models for managing these permissions. This note explores four key authorization models: Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), Relationship-Based Access Control (ReBAC), and Policy-Based Access Control (PBAC).

1. Role-Based Access Control (RBAC)¶

RBAC is one of the most common and straightforward authorization models. It manages permissions by assigning users to predefined roles, and each role is associated with a specific set of permissions.

Core Concept: Access is determined by the roles assigned to a user.
How it Works: Instead of assigning permissions directly to individual users, you assign permissions to roles (e.g., “Admin,” “Editor,” “Viewer”). Users are then assigned one or more of these roles. This simplifies administration, as you only need to update the role’s permissions to change access for all users assigned to that role.
Key Characteristics:
- Simplicity: Easy to understand and implement for systems with clear user hierarchies.
- Manageability: Reduces administrative overhead by managing roles instead of individual users.
- Static Nature: Can become rigid and lead to “role explosion” (a proliferation of roles) in complex systems where granular permissions are needed.
Real-World Example: A Blogging Platform
- Roles: Admin, Editor, Contributor, Subscriber.
- Permissions:
  - An Admin can manage users, settings, and all content.
  - An Editor can publish and manage posts from any user.
  - A Contributor can write and manage their own posts but cannot publish them.
  - A Subscriber can only read posts and manage their profile.
- Scenario: A new employee, Alice, joins the marketing team. She is assigned the “Editor” role, which automatically grants her the ability to review and publish articles.

2. Attribute-Based Access Control (ABAC)¶

ABAC, also known as Policy-Based Access Control (PBAC) in some contexts, is a more dynamic and fine-grained model. Access decisions are made based on a combination of attributes (or characteristics) of the user, the resource being accessed, the requested action, and the environment.

Core Concept: Access is granted based on attributes that describe the user, resource, and context of the access request.
How it Works: A central policy engine evaluates rules that combine various attributes. For example, a rule might consider the user’s department, the sensitivity level of the data, the time of day, and the user’s geographic location.
Key Characteristics:
- Granularity: Allows for highly specific and detailed access rules.
- Flexibility: Policies can be easily updated to reflect changing business needs without restructuring roles.
- Context-Aware: Incorporates real-time environmental factors into access decisions.
- Complexity: Can be more complex to set up and manage than RBAC.
Real-World Example: A Corporate File Server
- Attributes:
  - User: Job Title (e.g., “Accountant”), Department (e.g., “Finance”), Security Clearance (“Level 3”).
  - Resource: File Type (e.g., “Financial Report”), Sensitivity (“Confidential”).
  - Environment: Time of Day (e.g., “Business Hours”), Location (e.g., “Corporate Network”).
- Policy: “Allow users with the Job Title ‘Accountant’ to access files with Sensitivity ‘Confidential’ only during ‘Business Hours’ and from the ‘Corporate Network’.”
- Scenario: Bob, an accountant, tries to download a confidential financial report at 10 PM from his home network. Although his role is correct, the policy denies access because the time and location attributes do not match the rule.

3. Relationship-Based Access Control (ReBAC)¶

ReBAC is a model where permissions are defined by the relationships between entities in a system. It’s particularly powerful for applications that mimic real-world interactions, such as social networks, collaborative platforms, and hierarchical systems.

Core Concept: Access is determined by a user’s relationship to a resource.
How it Works: ReBAC defines permissions based on a graph of interconnected entities. For example, a user’s permission to edit a document is determined by whether they have an “owner” or “editor” relationship with that specific document.
Key Characteristics:
- Intuitive: Closely mirrors how ownership and sharing work in the real world.
- Scalable for Networks: Excels in systems with many interconnected objects and users, like Google Drive or Facebook.
- Inheritance: Naturally supports hierarchical permissions (e.g., access to a folder implies access to its contents).
Real-World Example: A Document Collaboration Tool (like Google Docs)
- Relationships: Owner, Editor, Viewer, Commenter.
- Entities: Users, Documents, Folders, Teams.
- Permissions:
  - If Sarah is the owner of “Project Plan.docx,” she has full control.
  - If Sarah shares the document with Tom as an editor, Tom can modify it.
  - If “Project Plan.docx” is in the “Marketing Team” folder, and Jane is a member of the “Marketing Team,” she automatically gets viewer access.
- Scenario: Tom, the editor, leaves the project. Sarah removes his “editor” relationship, instantly revoking his access without needing to change any roles or broad policies.

4. Policy-Based Access Control (PBAC)¶

While often used interchangeably with ABAC, PBAC can be seen as a broader implementation of the same philosophy. It formalizes the use of explicit policies that are decoupled from the application code. These policies are evaluated by a central decision engine.

Core Concept: Access is governed by a set of human-readable, centrally managed policies.
How it Works: An access request (e.g., “User Alice wants to ‘POST’ to ‘/api/transactions’“) is sent to a policy engine. The engine evaluates the request against its policy set, which can reference any number of attributes (user, resource, context), and returns a “Permit” or “Deny” decision.
Key Characteristics:
- Decoupled Logic: Authorization rules live outside the application code, making them easier to audit, update, and manage.
- Centralization: Provides a single source of truth for all access decisions across multiple services.
- Expressiveness: Policies can be written to handle very complex scenarios that would be difficult to code directly.
Real-World Example: A Financial Services Application
- Policy Language (simplified): “Permit a user to approve a transaction if the user’s role is ‘Manager’ AND the transaction amount is less than the user’s approval limit.”
- Policy Engine: Open Policy Agent (OPA) is a popular example.
- Scenario: A manager with a $10,000 approval limit attempts to approve a $15,000 transaction. The application queries the policy engine with the user’s attributes and the transaction details. The engine evaluates the policy, finds the amount exceeds the limit, and returns a “Deny” decision, which the application then enforces.

Summary Comparison¶

Model	Basis for Decision	Best For	Key Advantage
RBAC	User’s assigned role(s)	Systems with stable, well-defined user hierarchies	Simplicity and ease of management
ABAC	Attributes of user, resource, and environment	Dynamic, context-sensitive environments	Fine-grained, flexible control
ReBAC	Relationships between users and resources	Collaborative platforms and hierarchical systems	Intuitive for sharing and ownership models
PBAC	Centrally managed, explicit policies	Microservices architectures, complex compliance needs	Decoupling authorization logic from code

Page last modified: 2025-09-09 11:27:08