authz-rbac • Intermediate

Authorization Engines: Role-Based (RBAC) vs Attribute-Based (ABAC)

RBAC grants permissions based on static user roles (Admin, Editor, Viewer). ABAC (Policy Decision Points) evaluates fine-grained dynamic attributes (User Department, Document Owner ID, IP Geolocation, Working Hours).

Intuitive Mental Model

The Hospital Access Badge vs The Doctor On-Call Policy: RBAC is a plastic badge that says "Doctor" (opens the doctor lounge). ABAC checks: "Is this Doctor currently assigned to Patient #102, is the current time within their shift, and are they inside the surgical wing?"

Architecture Blueprint & CodeProduction Standard

// ABAC Policy Engine Evaluation:
interface PolicyContext {
  user: { id: string; role: string; department: string; ip: string };
  resource: { id: string; ownerId: string; confidentiality: string };
  environment: { currentHour: number; isVpn: boolean };
}

function canEditDocument(ctx: PolicyContext): boolean {
  // 1. Admins can edit anything:
  if (ctx.user.role === 'ADMIN') return true;
  
  // 2. Resource owner can edit if connected via secure corporate VPN:
  if (ctx.user.id === ctx.resource.ownerId && ctx.environment.isVpn) return true;
  
  // 3. Deny by default:
  return false;
}

Key Architectural Takeaways

•Role Explosion in RBAC: As permissions grow complex, RBAC creates dozens of rigid roles (BillingAdminUS, BillingAdminEU).
•ABAC Dynamism: Expresses contextual policies (e.g. "Only doctors on active shift in the pediatric department can view pediatric charts").
•Modern Engines: Open Policy Agent (OPA / Rego), AWS Cedar, Casbin.

Common Architectural Pitfall

Hardcoding static role checks (e.g. if (user.role === "admin")) across hundreds of route handlers, making policy updates impossible without code rewrites.

Production Best Practice

Use centralized policy evaluation middleware with ABAC / permission sets.

Next: Password Hashing: Argon2id vs bcrypt vs PBKDF2 & Salt Hardness