6 Dynamic authorization models

 

This chapter covers

  • How authorization evolved from simple role-based controls to dynamic, context-aware authorization
  • When and why to use relationship-based access control (ReBAC) for collaborative systems
  • How attribute-based access control (ABAC) enables fine-grained, real-time decisions
  • How policy-based access control (PBAC) unifies roles, attributes, and relationships
  • The tradeoffs and strengths of each model, and how to choose the right combination for your system

At first, ACME Corp’s switch to Role-Based Access Control (RBAC) seemed like a major breakthrough. After years of scattered Access Control Lists and inconsistent permissions, establishing a clear set of roles—customer support, sales manager, engineer, senior engineer—brought much-needed order to their internal systems. Onboarding got faster. Audits got cleaner. Developers could finally reason about access without digging through nested conditionals. But that clarity didn’t last.

As the company expanded into global markets and adopted more collaborative, multi-tenant services, cracks began to emerge. Roles multiplied, permissions drifted, and employees—especially those who wore multiple hats—began to complain.

6.1 Relationship-based access control

6.1.1 How ReBAC works

6.1.2 Mapping ReBAC onto the authorization reference architecture

6.1.3 Strengths and limitations of ReBAC

6.1.4 Where ReBAC makes sense

6.1.5 When ReBAC falls short

6.2 Attribute-based access control

6.2.1 How ABAC works

6.2.2 Mapping ABAC onto the authorization reference architecture

6.2.3 Strengths and limitations of ABAC

6.2.4 Where ABAC makes sense

6.2.5 When ABAC falls short

6.3 A hybrid approach: Policy-based access control

6.3.1 Policy as data

6.3.2 Policy as code

6.3.3 Beyond one-size-fits-all

6.4 Summary