RBAC in Practice: Where Role Models Actually Break Down

Designing a role model sounds straightforward until you try to mine roles out of years of direct entitlement assignment. Access that’s been granted one request at a time, with no role structure behind it, doesn’t cleanly resolve into a tidy set of roles — and the design choices you make about how to handle that mess determine whether the resulting model is maintainable or just a differently-shaped version of the same problem.

The role explosion trap

The naive approach to role mining is to look at existing access patterns and generate a role for every distinct combination that shows up. On a real enterprise application portfolio, this produces hundreds of near-duplicate roles — most of them representing one or two people’s specific, possibly outdated, access rather than anything resembling a genuine job function. It technically “models” the access, but it’s no more interpretable to a certification reviewer than the raw entitlements were, and it’s harder to maintain because now there’s a role layer to keep in sync too.

Coarse roles, governed exceptions

The trade-off that’s worked better in my experience: keep the role model deliberately coarse — a modest set of roles tied to department and job attributes that cover the common case — and route everything outside that common case through a governed access request rather than expanding the role model to capture it. This means some access won’t be “birthright” and will require an explicit request, which is a real cost in provisioning convenience. It’s a trade against a role model that grows without bound and eventually means nothing.

SoD rules need to live above the entitlement layer

Segregation of Duties rules defined against raw technical entitlements are hard for business stakeholders to evaluate — a rule like “cannot hold entitlement_4471 and entitlement_9902” doesn’t mean anything to the person who has to approve it. Defining SoD rules at the business-function level (e.g., “cannot both create and approve a payment”) and mapping those functions down to the technical entitlements that satisfy them keeps the rules something a business owner can actually reason about and sign off on — which matters, because SoD rule ownership belongs with the business, not with IT.

Migration without a big-bang cutover

Moving an active user population onto a new role model can’t happen as a single cutover without breaking access mid-task for real people. A phased migration — validating the role assignments for one application or business unit at a time before moving to the next — takes longer but avoids the operational risk of a wholesale switch.

The honest summary

RBAC design in an established enterprise is mostly a data problem wearing an access control costume. The technical mechanics of assigning roles are the easy part; deciding which historical access patterns represent a real role versus drift that shouldn’t be preserved is where the actual work is.