RBAC – Quick Thoughts from some Time in the Trenches

I’ve been working on a Role Based Access Control implementation at a large global bank for the past couple of years. In that time, I’ve experienced, first hand, the motivations for moving to a RBAC system, the pain involved, and have seen the benefits that are provided.

The biggest reasons for implementing RBAC were to improve access certifications/reviews and to reduce the amount of time that employees spent on those reviews and in requesting specific systems and applications access. The thought being that if we could “simplify” user access into predefined functional roles around the access needed to perform a particular job, we could then simplify the request for all that access from many requests down to one request. In addition, a person certifying access wouldn’t necessarily need to know what every access entitlement needed to perform the job was, they would just need to know that the role correlated with the job and certify that the user is in the correct role. The responsibility for ensuring that the proper access was contained within the role was given to the new concept of role owners.

On the surface, the reasons for wanting RBAC seem pretty logical and straight forward. Let’s reduce time “wasted” outside of performing our real jobs. Let’s make it easier for the managers tasked with certifying their employees’ access. Nobody is going to argue that those are bad ideas. Go ahead and implement RBAC! However, nothing worthwhile comes easy…or so I’ve been told.

The difficulty in implementation, to get those benefits, came in a few ways, none of which were insurmountable, but I just think they’re worth pointing out. You know, full disclosure and all. So, first, in order to simplify thousands of entitlements, we needed to catalog them and understand them. To do that, we had to talk with people (some more cooperative than others) across many teams and business units to get that information. Once we had all of that entitlement information collected and aggregated in our role management software, we needed to build efficient, purposeful roles that applied to each of the specific job functions throughout the organization. That required collaboration with most managers to identify groups of people performing similar jobs, where they would more or less need the same access to perform their day to day jobs. The hardest thing about this step was the time involved and getting the cooperation from the many business users needed to manage the roles. We required some back and forth communication, had to run reports on the many groups of people to identify all of their current access, and then had to build the foundation of the role that would apply to that group. At that point, it was up to the role owner to whittle the role down from the group’s total collection of access to what was determined to be required to perform the job. Finally, we had the makings of a role that we could build within the role management tool and assign to users.

What does any of this mean? Ultimately, I think that using RBAC is still a very good idea, it really does simplify things once all the constructs are in place. Future enhancements involve having HR systems changes automatically trigger role assignments and removals for employees, eliminating any time spent by employees requesting access. Just don’t be taken by surprise when you realize how many layers you have to peel back to get things built right, and how much time that takes. I’ve thought about it a lot and as far as I can see it, the only way to speed things up would have been to do it worse or add more people to the team. Neither of those were options we were willing to, or could, take!