Cut Off the Long Tail
Role Explosion Happens when you don't prioritize role creation by value.
Hi folks, John Thornton here. In the last two articles Nick Slabaugh recapped his experience at a large regional bank that had previously failed multiple times to implement an RBAC program. In the previous article he'd leveraged our RBAC approach and toolset to determine their optimum Role Model, but he wasn't out of the woods yet. His approach had its critics, I'll let him tell the story below:
Our previous efforts at the bank had revealed that the vast majority of value in the Role Model could be found in roles based on their job titles. The client's IAM team saw the calculations, agreed and we began to create those roles. The client's leadership was also excited at finally seeing forward momentum in their RBAC project and to create a role for every job title.
Every. Job. Title.
We had to instill some discipline, and it rapidly became contentious. Our toolset sorted role candidates in a graph from most to least valuable. Any Role Model is going to have a front-loaded set of roles that contain the vast majority of value, over time we'd come to find that this roughly mirrors the Pareto Principle. That graph generally looks like a left-facing brontosaurus with a very long tail of roles with too few people, too little access to be worth an RBAC program's time. Leadership wanted it built, but anyone who knows the term "role explosion" knows why you don't. We drew out that long tail for the client, and cut it off. The client was skeptical, at first, their enthusiasm for building a role for everyone was sincere, but when we put the data up on the screen and showed them the cutoff points, they understood that the meat was in the body. A group had to be large enough to be worth a role. Its members had to share the overwhelming majority of their access. And the attribute that named the group had to be populated reliably in HR, because a role built on a field that is blank for a third of the company is a role that assigns itself to no one. That last rule killed more candidate roles than any other, and it was one nobody had enforced before.
The result was a progressive set of roles, all with clear, dollars-and-cents value, that we could bring to the leaders of the division, department, or title they affected. We could lay out how common the access was, why it was clearly delineated for those users, and the direct value it would bring to the company - literally person-hours saved with every line item. Importantly, none of it was imposed from above. Business owners saw the candidates, understood how each one was derived, and approved or rejected them on the spot as we guided them through what every piece of data, every account, meant.
What a decade of committees had not shipped, we had a defensible model for in a matter of weeks. In three months, we had pilots in production that were set to save the company 2500 access requests a year. By the time we finished, we had covered almost 60% of total access in the entire organization - more than 50,000 individual groups, accounts, and privileges.
RBAC does not die in production because it is impossible. It dies when you start from the wrong end.










