concept

Role Explosion

The proliferation of narrowly-scoped roles that occurs when RBAC is used to express rules that actually depend on context.

rbacauthorizationscale

RBAC is simple and auditable while permissions depend only on who someone is. It degrades when the real rule depends on context: a manager may approve expenses in their own department, under a threshold, during their tenure.

RBAC cannot express that, so people encode the context in role names — expense-approver-finance-emea, expense-approver-finance-apac, expense-approver-sales-emea — and the count multiplies with each dimension. Organisations routinely end up with thousands of roles, nobody able to say what any particular one grants, and access reviews that are performed by clicking approve.

The signal to watch for is roles whose names contain a dimension — a region, a department, a product, a customer. That is the point at which the model has run out.

The remedies. ABAC evaluates attributes of subject, resource, action and environment, so one policy covers every department. ReBAC answers relationship questions — "is this user a member of a team that owns this record?" — which is what document and collaboration systems need.

The pragmatic path is usually hybrid: coarse RBAC for broad capability, with attribute or relationship checks for the contextual part. And whatever the model, centralise the decision so it can be audited and changed in one place, while keeping enforcement at every resource.