Just to be clear, my issue with RBAC has nothing to do with security altars and everything to do with pragmatism as to how RBAC is sold and practiced in the real world. Managers who buy into RBAC look at the concept and it seems great to them...."hey! i was just looking at the org chart! i know what roles we need. i am half way there!"

the us military has had colonels reporting to general and majors reporting to colonels a hundred years ago and will a hundred years from now. rbac in this situation? ya sure, ya betcha. saddle up, let's ride.

in enterprise companies riven with acquisition, quarterly re-orgs, insanely multi-tasked employees, outsourcing and feverish decentralization? well then i am a little less sanguine about its ability to scale across the enterprise.

as an analyst at a not so big but very smart analyst firm told me "the road is littered with dead bodies of people who have tried enterprise wide rbac."

does rbac have its uses in enterprises? sure.

but as napoleon said the fifth element is mud. ya gotta be able to deploy and scale this stuff beyond the whiteboard. in practice i have found groups and attributes more useful.

anyhow, keep up the good work.
 

[This opinion is also posted at www.EntitlementBlog.com, the only blog dedicated to the topic of Entitlement Management.]

It is often good to have a food fight in order to get to the meat of an issue (!). But it is often dangerous to jump in late into a food fight lest everybody take aim at you. However let me do just that and weigh in on this very interesting discussion.

My comments are biased by own experiences as a customer of authorization solutions and also from the experiences of enterprises I know intimately. While it may seem impossible, what with all the emotion-charged words flying around, I think James, Gunnar, and Dave are all correct. Let me explain.

The ultimate goal of any identity or access management solution is to ensure that access to a resource is granted only when appropriate. This requires that for every access to a resource we need to determine who is making the access and then determine if this particular request should be granted or not. In fact we don’t really need to know everything about the end-user but only those attributes pertinent to the request – so for example when I am buying a can of beer the sales person does not really care to know who I am but only the fact that I am over 21 years of age. In this context, only a subset of my attributes is necessary to be reviewed or disclosed. Similarly when I am signing my daughter out of her preschool, the only attribute that matters is whether I am her father or registered guardian. My age is not pertinent to that access.

So where do roles fit in? A role is simply another attribute. I can be a “guest” in one application, a “registered user” in another, and an “administrator” in the third. In the simple case the first application only cares to know what role I have for that application (the case where I cannot be a guest in application A if I am an administrator of application C is a simple extrapolation of the arguments made in this post). There also may be a set of “universal” attributes that all applications care about, for example, whether I am a “current employee” of the organization. There are other non-user attributes that are oftentimes pertinent to making the access decision, for example a document resource may have an attribute, say “clearance level”, and access requires confirming that the security clearance level of the end-user (a user attribute) is equal to or greater than the clearance level of the document (a resource attribute). Environment attributes may include “time of day”, message attributes may include “$ value of the transaction being attempted” or encryption key length, and so on.

I don’t think anyone is arguing whether attributes (user, resource, message/access, environment, etc.) are important in making (and enforcing) access decisions. And I think we are all in agreement that access should be driven by rules and not some manual mapping of this collection of attributes.

I think the potential disagreement lies in our implicitly held beliefs on the most effective way that these attributes should be defined and how they should be managed. Should there be a special set of attributes called “roles”, should these special role attributes be defined top-down in an organization, and should these special role attributes be managed by a central entity? Treating some user attributes as special role attributes begs the question of what makes some attributes special and not others. The age attribute is critical to buying beer, just as the father attribute is critical to picking up my daughter – should these be roles? Likely not. Should “Sales Manager” be a role. Possibly yes. But if a sales manager of EMEA should have different access than the sales manager from Asia Pac, should we have two different roles, “Sales Manager EMEA” and “Sales Manager Asia Pac”? And then should we have “Sales Manager EMEA before 5pm” and “Sales Manager EMEA after 5pm”? You get my drift. If we are not careful we will end up in an unmanageable explosion of roles. However what is clear is that whether we have special attributes called roles or not, we will still need to have additional user attributes that determine access.

Gunnar and James are arguing for attribute-based, dynamic rule-driven access control. And so is Dave. But perhaps where they differ is their preference for attribute definition and management that is top-down or attribute definition and management that is delegated to the application owners and administrators. Whether the attributes should be more broadly visible, perhaps globally visible or not, whether they should have some form of permanence, whether they can be inherited or cloned, and whether they can be discovered or mapped should be possible in either approach. I don’t think anyone is arguing against these capabilities. And for some of these capabilities, in particular attribute discovery and mapping, there are specialist “role management” companies.

In my experience the best approach is based on controlled delegation where the definition and management of application or resource specific user attributes is delegated to the owners and administrators of the resource but there is central visibility and oversight. As an example if my daughter’s school wants to define and use the “parent or guardian of” attribute, perhaps by asking for my daughter’s birth certificate, that is of no interest to the liquor stores in the world who care that I am of legal drinking age. Since these attributes are application-specific, it is best that they be defined and managed by the application owners or administrators. And because they are delegated and application-specific we are spared the m times n problem.

However what happens when an application owner wants to share attributes or piggyback on the attribute definition and validation that has been done by others? So for example many application owners in an enterprise care about the “is current employee” attribute and in most cases it is appropriate for this attribute to be defined and managed centrally, most likely through a centrally deployed HR system. An effective attribute-based, dynamic rule-driven access control system should allow for attributes to be shared and scoped. In the general case an attribute source should be treated as just another protected resource that can be used by other resources based on attribute-based rule-driven access control.

Since an application or resource in an enterprise may have multiple owners or at least multiple independent entities who need to have a say in the access rules for a resource (for example the application team, the compliance team, the InfoSec team, etc.) it is important that the system allow for multiple entities, central or distributed, that autonomously can define attribute-based access rules for a given resource, and where the inevitable conflicts in the rule decisions (in many cases these conflicts are good and are an example of oversight) can configurably and deterministically be resolved and audited.

This approach leads to a very consistent, scalable, extensible, and manageable access control architecture. And most importantly one that is practical, and that successfully has been deployed by enterprises across the spectrum of size, compliance, security, and governance needs, and internal control cultures. And I have successfully avoided making a product plug. If you want to send me email privately, please do so at rgupta@securent.com.