Thursday, September 06, 2007
The rules about rolesShekhar Jha recently posted a note about roles and role management, where he states: "I have always considered roles as a means to achieve the end goal of access management." But feels that others have a different view: "But a lot of people do see the roles themselves as something important that need to be 'mined' out of privileges." He adds, "I may be slightly biased against the role-management because I see the end goal as Access Management and not role management."
I've spoken before about the two differing approaches to role definition. First there's the top-down method of starting with the compy's org chart, squeezing in HR's job definitions, tacking on regulatory "must"s and "must not"s then tweaking for individual enterprise activity. Secondly there's the bottom-up method of discovering access rights by trolling the network then creating roles based on common access rights. This latter case is what's known as "role mining."
The reality is, of course, that you need both. Relying solely on role mining leads to compounding all of the errors that have built up over time - and they can be enormous. But creating roles simply by copying the org chart means you end up with a "mission statement for rights" which, like your enterprise's other Mission Statement, looks good, sounds good and it's much more likely to be honored in the breach than in the observance.
We need to think of roles as an abstraction layer for identity.
We're abstracting needs and requirements from the mass of individuals within the organization but at the same time we're abstracting rights and privileges from the resources that are the targets of the users' needs (some would call this abstraction "entitlements"). The use of an abstraction layer allows us to construct access rules which are easily, but securely, enforced by the system while also automating set-up and tear-down of the access. Roles make the job of managing users and their access rights and needs far easier, far more automated and far more auditable.
Roles are necessary, but not sufficient, for a well designed identity management system.
I (Shekhar) am not questioning the significance of role as an abstraction layer (as this is something I have made clear during my earlier writing - see http://identityaccessmanagement.blogspot.com/2004/06/identity-and-access-management-part.html
What I am trying to understand is whether Roles as we understand it today (i.e. NIST Roles) is enough for the real world scenarios and if not then what are the characteristics that are missing from the roles as we know today(for example context).
What is missing is the Rules Management. Having an effective Role Management would also require a seamless integration with the existing workflows
Based on my experience, I have two (quite sad) observations:Post a Comment
1) Top-down approach does not work. It is quite infeasible even for small organizations. Nobody usually knows what privileges should belongs to "Garbage Administrator, 3rd class". Especially if garbage admins in Foo department do a slightly different job than those in Bar department. And when you sort that out, someone will do cost-saving reorg and half of the garbage admins will take the roles of both Foo and Bar. Whatever model you bring, you will find thousands of exception even before your deployment ends pilot phase. If you just ignore that and force your project over such "banal" issues, you risk business interruption. And you know ... business first.
2) Role mining does not work either. As you said, it is just a "legalization of chaos". This will make things look better, but will not really solve the problem.
Some quite different solution is needed. But I'm not sure what it is ...
© 2003-2006 The Virtual Quill, All Rights Reserved Home