IDM: Roles, Authorization and Data Centric Security
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. Share:
