Designing an Access Control System

Access control governs who can do what to which resources — one of the most foundational security concerns in system design.

Access Control Models

RBAC — Role-Based Access Control

User → Roles → Permissions

User: Alice
Roles: [editor, team_lead]
Permissions:
  editor:     create_post, edit_post, delete_own_post
  team_lead:  delete_any_post, manage_members

Alice can: create_post, edit_post, delete_any_post, manage_members

ABAC — Attribute-Based Access Control

Policy: IF user.department = resource.department
        AND user.clearance >= resource.classification
        AND time BETWEEN 09:00 AND 18:00
        THEN ALLOW

More expressive, more complex to manage

ReBAC — Relationship-Based Access Control

Google Zanzibar model:
  document:123 has viewer: group:engineering
  group:engineering has member: user:alice
  → Alice can view document:123

Check: can(alice, view, document:123)?
→ Traverse relationship graph

Open Policy Agent (OPA)

General-purpose policy engine:

# Rego policy
default allow = false

allow {
  input.user.role == "admin"
}

allow {
  input.user.role == "editor"
  input.action == "read"
}

allow {
  input.user.id == input.resource.owner_id
  input.action in ["read", "write", "delete"]
}

Authorization Architecture

Request: Alice → edit post:123
    ↓
AuthZ Service (OPA / Zanzibar)
    ↓
Policy Evaluation:
  Fetch: Alice's roles
  Fetch: post:123 attributes
  Evaluate: policies
  Decision: ALLOW / DENY
    ↓
Service applies decision

Permission Storage

-- RBAC tables
roles(id, name, description)
permissions(id, resource, action)
role_permissions(role_id, permission_id)
user_roles(user_id, role_id, scope_id, expires_at)

Caching Permissions

Permission decisions cached in Redis:
  key: authz:{user_id}:{resource}:{action}
  TTL: 60 seconds

Cache invalidation on:
  Role assignment changes
  Permission policy updates

Audit Trail

Every authorization decision logged:
{ user, action, resource, decision, policy_matched, timestamp }

Enables:
  Compliance reporting
  Anomaly detection
  Debugging access issues

Conclusion

RBAC is simple and sufficient for most applications. ReBAC (Google Zanzibar model) handles complex social/hierarchical permissions. OPA provides a flexible policy engine that works across any infrastructure layer.