There were some great comments on my last post, which bring to light a serious problem with the way authorization is done today and how roles don’t help as much as we’d like. First we hear from LonerVamp:
And even if you get the authentication part down, very few apps that I’ve seen then tie back into whatever is in place for role management.
This is an important point that often gets glossed over by IDM vendors. It turns out that while many applications have support for third party authentication mechanisms, very few have support for third party authorization methods. Which means that even if you can centralize your identities for the purposes of account creation/deletion, you still have to manage use inside each application. Furthermore, many of the applications that claim to support third party authorization really turn out to only support third party groups in LDAP or RADIUS, but you still have to map those groups onto roles within the applications.
Andrew Yeomans followed up with his own comment that shows that he’s been a dedicated Securosis reader for a while now:
I’m starting to think that a data-centric approach may be a way forward.
Today, authorizations are generally enforced by applications. Now firstly this leads to high complexity (as you describe) as there is no unifying set of “policy decision points” and “policy enforcement points”. Secondly, it allows for authorization restrictions to be bypassed by other applications that have access to the same data.
Andrew really hits the nail on the head here. We need to continue our shift towards Data-centric Security. The Data Security Lifecycle explicitly assumes that you can properly assign and control rights to who has what data, which is why IDM is so important. I’ve said it before and I’ll say it again: If you don’t know who is accessing the data, how can you possibly tell if it is being abused or misused?
Finally Omie asked:
I’ve been hearing too much about identity management recently and how the move to roles will solve our compliance problems. And I’ve been wondering and asking how we plan to keep the roles maintained over time. Of course I’ve also been under the impression that every other organization has figured that out except ours, but your post is making me rethink that assumption. If there are some best practices/examples of how to approach role maintenance, I would love to learn about them.
Roles can definitely help you out with compliance, but you are correct – role maintenance is definitely a challenge. There is often an implicit assumption that roles, like the rest of the application configuration, are static, when in reality roles tend be dynamic so you absolutely need a process for adapting roles as necessary. Often the complexity of the application causes admins to add roles rather then edit the existing ones because it is easier in the short term. But in the long run this causes extra complexity. I’ll go into more details on this issue and how to deal with it in a later post, so stay tuned. In the meantime, NIST recently published some documents from their recent Privilege (Access) Management Workshop. In particular, you should check out A Survey of Access Control Models, to give you an idea of some ways that role based access control is problematic.
Reader interactions
2 Replies to “IDM: Roles, Authorization and Data Centric Security”
Roles are a poor compromise, between strong security and manageble administration.
And you know what? It doesn’t work. Most often RBAC provides neither good security, nor makes the system manageble. Roles are a good concept, however they are FAR over-used.
But it’s not the roles’ fault, its ours as an industry – we haven’t actually provided a better solution yet, “better” meaning good, fine-grained authorization, together with being able to scale well enough to continue managing hundreds of thousands of users, across hundreds of systems… I’ve taken to calling this “scalable granularity”.
And no, none of the current batch of IdM/IAM products out there solve it… In fact, they often make the situation worse, as you’ve pointed out.
I’ve been banging that particular drum for several years, usually takes a while for that message to sink in… and I’m even doing some in depth research for a real solution – “scalable granularity” being the goal.
Glad to see some more folks on this wagon.
Roles are great. Roles provide us a template to define access to resources. They save us time and money as we can quickly assign a behavioral profile to users. Set once, define many. The problem is they are fragile and we apply the same role across different data types and resources with differing use case assumptions. Roles are a rigid model, requiring an exception for every user who needs to work in a way unanticipated or uses for data that were unforeseen. A few dozen or even 100 roles are manageable. The thousands of exceptions piled on top of the roles becomes a nightmare. I don’t see the problem with the roles per se, but as you pointed out, in how we handle the exceptional cases. Which in most cases is ad-hoc and inconsistent and without revocation over time. Rules as a tool fail when the complexity outgrows our ability to manage or even comprehend.
The advantage with Data Centric Security is context, and the application will understand the defined behaviors in context of the lifecycle stage and application that governs use. Context gives us greater granularity over authorization. Really that is the advantage. Application developers need to code in those extra rules. And anticipate the use cases. They are no longer a simple ‘yes or no’ filter but a moderately complex decision tree or even behavior based access. Further, even in a Data Centric model, we still must provide means for users to customize those roles to alter behaviors. Data Centric Security can be an advancement but requires the investment in development or customization … which is what we fail to do with roles. DCS does not necessarily circumvent existing problems.