Decision Maker

Why Role-Based Access Management Is Hard

• By Don Jones
• 02/01/2011

These days, we're constantly hearing about role-based access management. The theory is that instead of putting your users into groups, you put them into roles, which correspond to their actual job titles. Magically, their role memberships get them access to all the files, folders, databases, mailboxes and whatnot that they need.

I've recently had some spirited conversations with consulting clients who don't entirely understand the complexity of role-based access (RBA), and who insist that role is just another word for the native groups in Windows. Nothing, unfortunately, could be further from the truth.

Sure, you could create a domain security group named "Inside Salespeople," which corresponds to a job role. That might even make a convenient e-mail distribution list, killing two birds with one stone. And provided the only resources they'll need access to are files, folders and perhaps SQL Server databases, you might well have achieved RBA -- if all of those resources are within a single domain or within fully trusting domains. And if you completely trust your administrators. That's a lot of caveats -- and it's why user groups don't constitute role-based administration.

Groups are a technical implementation, whereas RBA is a logical, policy-based element of your network. Think about it for a second, and you'll know it's true. What happens when someone new joins your organization? One of the first questions anyone asks is, "What access do they need?" The answer is usually, "The same access as Bob" -- or Joe or whoever else is in a similar position. Then you have to figure out what access Bob has. Usually, Bob's a member of numerous user groups, so you have to start duplicating those memberships. This is not RBA. With true RBA:

1. You need zero awareness of the underlying permissions mechanisms in order to put the person into the correct role.
2. The people who control permissions (for example, administrators) don't necessarily need to have any control over role membership.

That second point is important because it represents a separation of duties. An admin might modify a user group's membership, but he shouldn't be able to modify a role's membership. That right there tells us that user groups alone don't constitute RBA.

The sad fact is that Windows does not support RBA natively. Even in the smallest environments where groups might be aligned directly to roles, you still can't achieve the separation of duties necessary to make RBA happen. In order to achieve true RBA, you're going to need a third-party product of some kind that adds an additional layer to your security infrastructure. You'll define your roles in that product, and that product may well utilize user groups as a means of granting the necessary permissions. In other words, user groups remain an implementation mechanism -- but they're managed through an automated layer that uses them as a means of implementing RBA.

It works something like this: Someone from Human Resources puts a new user into the "Inside Salespeople" role. The RBA-management layer has been told what user groups (and other implementation mechanisms) comprise that role, and so it adds the user into those groups. If the user is removed from that role in the future, he comes out of those groups, too. But this isn't just Windows user groups: A good RBA system is also cross-platform, meaning the user might also be added to SAP R/3 groups, Oracle groups and other security implementation mechanisms. That's the real key here: You're abstracting the implementation of the security away from the business layer.

But doing RBA isn't the hard part.

The hard part of RBA is deploying it. That's because first you have to define job roles, and then figure out what resources each one needs permissions for. Sounds awfully difficult, doesn't it? Figuring out every little thing each job title has access to? The solution is in finding an RBA-management layer than can help with this deployment step. As I noted, RBA is easy from a software-programming perspective. Getting tools that can help inventory your current permissions and map that into roles -- that's the tricky bit, and there's where you'll be evaluating potential vendors for RBA products.