5 Static authorization models

 

This chapter covers

  • Distinguishing static versus dynamic authorization models
  • Managing permissions with Access Control Lists (ACLs)
  • Assigning access through Role-Based Access Control (RBAC)
  • Mapping ACLs and RBAC to the reference architecture components
  • Evaluating the strengths and limitations of static models
  • Identifying where ACLs and RBAC still make sense in modern systems

When ACME Corp launched its first SaaS product, authorization was an afterthought. With a handful of developers and a few early customers, it was easy to hardcode access to the admin dashboard and restrict sensitive features to known team members. Everyone had access to staging environments, and customer data was stored in separate folders, protected more by convention than by control.

As the company grew—from a scrappy startup to a fast-scaling enterprise—its access control needs became more complex. Contractors needed limited access to customer support tools. Sales reps required region-based access to accounts. Engineering teams asked for staging environments with access scoped by project. Support teams needed the ability to debug customer issues without compromising security. And Finance needed better understanding of access for regulatory compliance.

5.1 Access Control Lists (ACL)

5.1.1 How ACLs work

5.1.2 Mapping ACLs onto the authorization reference architecture

5.1.3 Strengths and limitations of ACLs

5.1.4 Where ACLs still make sense

5.1.5 When ACLs fall short

5.2 Role-Based Access Control (RBAC)

5.2.1 How RBAC works

5.2.2 Mapping RBAC onto the authorization reference architecture

5.2.3 Strengths and limitations of RBAC

5.2.4 Where RBAC still makes sense

5.2.5 Where RBAC falls short

5.3 Beyond static authorization

5.4 Summary