Authorization Models: RBAC and ABAC

Authorization Models: RBAC and ABAC: Core Concepts

Authentication answers "who are you?" Authorization answers "what are you allowed to do?" After a user proves their identity, the system must decide whether to grant access to a specific resource. The two dominant models for making this decision are Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC).

Role-Based Access Control (RBAC)

RBAC assigns permissions to roles, and users are assigned to roles. A user inherits all permissions of their roles. This indirection between users and permissions simplifies administration: when a new employee joins, you assign them the appropriate role rather than configuring individual permissions.

Users → Roles → Permissions → Resources

Core concepts:

• User — A person or service account that needs access
• Role — A collection of permissions (e.g., "Editor", "Viewer", "Admin")
• Permission — An action on a resource (e.g., "read:document", "delete:user")
• Session — A user activates a subset of their assigned roles for a given context

Example RBAC policy:

roles:
  viewer:
    permissions:
      - resource: documents
        actions: [read]
  editor:
    permissions:
      - resource: documents
        actions: [read, write]
    inherits: [viewer]
  admin:
    permissions:
      - resource: documents
        actions: [read, write, delete]
      - resource: users
        actions: [create, read, update, delete]
    inherits: [editor]

user_assignments:
  alice: [editor]
  bob: [viewer]
  carol: [admin]

RBAC is simple to understand and audit. However, it can suffer from role explosion: as the organization grows, the number of roles increases combinatorially because each combination of permissions may need its own role.

Attribute-Based Access Control (ABAC)

ABAC evaluates policies against attributes of the user, resource, and environment. Instead of assigning permissions to roles, you define rules that match on attributes:

Permit if user.department == resource.department AND user.clearance >= resource.classification

Core concepts:

• Subject attributes — Properties of the user (department, clearance level, job title)
• Resource attributes — Properties of the resource (owner, classification, department)
• Action attributes — The operation being performed (read, write, delete)
• Environment attributes — Contextual factors (time of day, location, device type)

Example ABAC policy (XACML-style):

<Policy RuleCombiningAlg="first-applicable">
  <Rule Effect="Permit" RuleId="same-department-read">
    <Condition>
      <Apply FunctionId="string-equal">
        <AttributeValue>read</AttributeValue>
        <SubjectAttributeDesignator AttributeId="action"/>
      </Apply>
      <Apply FunctionId="string-equal">
        <SubjectAttributeDesignator AttributeId="department"/>
        <ResourceAttributeDesignator AttributeId="department"/>
      </Apply>
    </Condition>
  </Rule>
  <Rule Effect="Permit" RuleId="owner-full-access">
    <Condition>
      <Apply FunctionId="string-equal">
        <SubjectAttributeDesignator AttributeId="id"/>
        <ResourceAttributeDesignator AttributeId="owner"/>
      </Apply>
    </Condition>
  </Rule>
  <Rule Effect="Deny" RuleId="default-deny"/>
</Policy>

ABAC is more expressive than RBAC but also more complex. It requires a Policy Decision Point (PDP) that evaluates policies and a Policy Enforcement Point (PEP) that intercepts access requests.

RBAC vs. ABAC Comparison

Where It Fits

Authorization is the third pillar of identity security: Authentication (who are you), Authorization (what can you do), and Auditing (what did you do). Study Authentication Factors and MFA first to understand how identity is established, then move to SSO and Federation to see how authorization decisions are shared across systems.

Authorization Models: RBAC and ABAC: Practice

Authorization models are best understood by implementing them. The exercises below cover both RBAC and ABAC in a realistic application context.

Exercise 1: Implement RBAC in Python

from enum import Enum
from functools import wraps

class Permission(Enum):
    READ = "read"
    WRITE = "write"
    DELETE = "delete"

class Role:
    def __init__(self, name, permissions=None, inherits=None):
        self.name = name
        self.permissions = set(permissions or [])
        self.inherits = inherits or []
    
    def get_effective_permissions(self, all_roles):
        effective = set(self.permissions)
        for parent_name in self.inherits:
            parent = all_roles[parent_name]
            effective |= parent.get_effective_permissions(all_roles)
        return effective

class RBAC:
    def __init__(self):
        self.roles = {}
        self.user_roles = {}
    
    def add_role(self, role):
        self.roles[role.name] = role
    
    def assign_role(self, user, role_name):
        self.user_roles.setdefault(user, set()).add(role_name)
    
    def check_permission(self, user, permission):
        for role_name in self.user_roles.get(user, []):
            role = self.roles[role_name]
            if permission in role.get_effective_permissions(self.roles):
                return True
        return False

# Usage
rbac = RBAC()
rbac.add_role(Role("viewer", [Permission.READ]))
rbac.add_role(Role("editor", [Permission.WRITE], inherits=["viewer"]))
rbac.add_role(Role("admin", [Permission.DELETE], inherits=["editor"]))

rbac.assign_role("alice", "editor")
print(rbac.check_permission("alice", Permission.READ))   # True (inherited from viewer)
print(rbac.check_permission("alice", Permission.WRITE))  # True
print(rbac.check_permission("alice", Permission.DELETE)) # False

Exercise 2: Implement ABAC Policy Evaluation

class ABAC:
    def __init__(self):
        self.policies = []
    
    def add_policy(self, policy):
        self.policies.append(policy)
    
    def evaluate(self, subject, resource, action, environment):
        for policy in self.policies:
            result = policy.evaluate(subject, resource, action, environment)
            if result == "Permit":
                return True
            if result == "Deny":
                return False
        return False  # Default deny

class Policy:
    def __init__(self, effect, conditions):
        self.effect = effect  # "Permit" or "Deny"
        self.conditions = conditions
    
    def evaluate(self, subject, resource, action, environment):
        for condition in self.conditions:
            if not condition(subject, resource, action, environment):
                return "NotApplicable"
        return self.effect

# Define conditions
def same_department(subject, resource, action, env):
    return subject.get("department") == resource.get("department")

def action_is_read(subject, resource, action, env):
    return action == "read"

def business_hours(subject, resource, action, env):
    hour = env.get("hour", 0)
    return 9 <= hour <= 17

# Usage
abac = ABAC()
abac.add_policy(Policy("Permit", [same_department, action_is_read]))
abac.add_policy(Policy("Permit", [business_hours]))

subject = {"department": "engineering", "id": "alice"}
resource = {"department": "engineering", "classification": "internal"}

print(abac.evaluate(subject, resource, "read", {"hour": 14}))   # True
print(abac.evaluate(subject, resource, "write", {"hour": 14}))  # False
print(abac.evaluate(subject, resource, "read", {"hour": 20}))   # False (after hours)

Exercise 3: Hybrid RBAC + ABAC

Most real systems use a hybrid approach: RBAC for coarse-grained access, ABAC for fine-grained decisions:

def check_access(user, resource, action, environment):
    # Step 1: RBAC check — does the user's role allow this action type?
    if not rbac.check_permission(user.role, action):
        return False
    
    # Step 2: ABAC check — do the attributes allow this specific access?
    if not abac.evaluate(user.attributes, resource.attributes, action, environment):
        return False
    
    return True

Check Your Understanding

• What is role explosion and how does it affect RBAC at scale?
• What are the four types of attributes in ABAC?
• Why is default-deny a critical principle in both RBAC and ABAC?

Authorization Models: RBAC and ABAC: Trade-offs and Interviews

Choosing between RBAC and ABAC is one of the most consequential architectural decisions in identity security. Each model has strengths and weaknesses that make it suitable for different scenarios.

When RBAC Is the Wrong Tool

• Fine-grained access control: If you need to restrict access based on resource attributes (e.g., "users can only access documents in their department"), RBAC requires a role for each department, leading to role explosion.
• Dynamic access decisions: If access depends on context (time of location, device), RBAC cannot express these conditions without creating roles for every combination.
• Large user populations: In systems with millions of users and thousands of resources, managing individual role assignments becomes unwieldy. ABAC's attribute-based rules scale better.

When ABAC Is the Wrong Tool

• Simple applications: If you have a handful of user types (admin, editor, viewer), RBAC is simpler to implement, audit, and maintain.
• Regulatory compliance: Some regulations require that access be auditable by role. ABAC policies can be difficult to audit because the effective permissions depend on runtime attribute values.
• Performance-critical systems: ABAC policy evaluation is slower than RBAC role lookup. In high-throughput systems, this latency may be unacceptable.

The Principle of Least Privilege

Regardless of the model, always apply the principle of least privilege: grant only the minimum permissions necessary for a user to perform their job. This limits the damage from both external attacks and insider threats.

Implementing least privilege:

1. Start with no permissions and add only what is needed
2. Regularly review and remove unused permissions
3. Use just-in-time (JIT) access for privileged operations
4. Implement access reviews where managers certify their team's permissions

How This Comes Up in Interviews

• "What is the difference between RBAC and ABAC?" RBAC assigns permissions to roles and users to roles. ABAC evaluates policies against user, resource, and environment attributes. RBAC is simpler but less flexible; ABAC is more expressive but more complex.
• "How do you prevent role explosion in RBAC?" Use role inheritance (roles inheriting permissions from other roles), separate roles by function rather than by individual, and supplement with ABAC for fine-grained decisions.
• "How do you implement least privilege?" Start with no permissions, add only what is needed, regularly review and remove unused permissions, use just-in-time access for privileged operations, and implement regular access reviews.