Identity & Access · Chapter 4 of 16
Entitlements, RBAC and ABAC
How permission models actually decay, and why role explosion is a design failure rather than bad luck.
RBAC groups permissions into roles and assigns roles to people. ABAC decides from attributes at request time — department, location, device posture, data sensitivity, time of day. Most real systems are a hybrid, and the interesting question is not which is better but how each one fails.
| Fails by | Looks like | |
|---|---|---|
| RBAC | Role explosion | 1,800 roles for 900 employees; a role per person, in effect |
| ABAC | Unanswerable questions | Nobody can say who can reach a system without running the engine |
| Hybrid | Two sources of truth | A role grants it, a policy denies it, and nobody knows which wins |
Role explosion happens because each exception becomes a new role rather than a policy. It is the accumulated debt of a thousand reasonable one-off decisions, and once you are past a few hundred roles the model no longer describes anything a human can reason about.
Policy-as-code, and why it is worth knowing about
The current direction of travel is externalised authorisation: a policy engine — Open Policy Agent with Rego, AWS Cedar, OpenFGA — that applications call to ask “may this subject do this action on this resource?” The policy lives in version control, gets code review, and can be tested.
- For engineers: this is a genuinely growing specialism and it appears in 44% of the identity job descriptions in this atlas — higher than directory work.
- For auditors: it is a gift. Policy in a repository with commit history and tests is dramatically better evidence than permissions configured by hand in twelve consoles.
- The catch: a policy engine that is not consistently called is decoration. The audit question is not “do you have OPA?” but “which code paths bypass it?”
Segregation of duties, stated usefully
SoD means no single person can both initiate and approve the same consequential action — create a vendor and pay it, write code and deploy it to production unreviewed, grant themselves access and use it. It is one of the few identity controls that regulators test directly, and it is usually implemented as a set of forbidden entitlement pairs.
The audit question that finds real problems: “show me someone who holds both halves of a conflicting pair” — and then check whether the compensating control that was documented actually operates.
Why role models decay, and what to do about it
Role-based access begins as a clean idea: define roles that match jobs, assign people to roles. It decays in a predictable way, and knowing the mechanism lets you design against it.
- Someone needs one extra permission. Adding it to the role would over-grant everyone else, so a new near-duplicate role is created.
- Repeat for three years. You now have more roles than people — ‘role explosion’ — and the model no longer explains anything, because understanding someone's access means reading a list rather than knowing their job.
- Nobody deletes a role, because nobody can prove it is unused, so the count only ever rises.
- The tell: if your role count exceeds your headcount, you have an entitlement list wearing the costume of a role model.
| Model | Grants on | Best at | Worst at |
|---|---|---|---|
| Role-based | Who you are | Being explainable to an auditor and to the person granting it | Anything contextual — it cannot express 'only during business hours' or 'only their own region' |
| Attribute-based | Properties of user, resource and context | Expressing the rules that role models cannot | Being explainable. 'Why can this person see this?' becomes a debugging exercise |
| Relationship-based | The graph — owner, member, parent | Hierarchies and sharing, which is why document and repository products use it | Bulk organisational policy |
| Policy-as-code | Evaluated rules, versioned and tested | Being reviewable, testable and consistent across services | Requiring engineering ownership — it is software, and it needs the discipline of software |
What works in practice is a hybrid with a rule about where each lives: roles carry the coarse, stable grants that map to jobs and can be explained to an auditor; attributes and policy carry the contextual conditions — region, time, ownership, data classification — that roles genuinely cannot express. Trying to force context into roles is what causes the explosion.
The two questions that assess any entitlement system
“Can you tell me everything this person can access, in one query?” If the answer requires visiting six consoles and reading a spreadsheet, then nobody has ever genuinely reviewed anyone's access, whatever the review records say.
“Can you tell me everyone who can access this resource?” The reverse direction, and much harder. It is also the question asked during every incident and every regulatory enquiry, which is a bad time to discover the system cannot answer it.
Most systems answer the first badly and the second not at all, because entitlement data lives in each application rather than in one queryable place.
Which is the actual argument for centralising entitlement data — not control, which stays with the applications, but answerability. And it is a far more honest justification for a governance platform than a compliance checkbox.
A third, if you want to be pointed: “what fraction of granted entitlements have been used in the last ninety days?” The answer is usually well under half, and it is the cleanest available evidence that least privilege is aspirational.
Check yourself