Brendon Unland's Blog

I don’t like the word “Entitlement Management” and I never have. When the word was coined around 2007, Entitlement Management was given the definition of “a new way to bring about fine-grained access control.” I thought it was a slick way to say,

“Hey, now that you have Identity Management…you need Entitlement Management!”

Other bloggers have written about the distinction between Entitlement Management as a process (something like role management, I think) vs. a run-time fine grained XACML based (i.e., PEP, PDP, PIP, PAP, etc.) authorization architecture (e.g. Ian Yip)  I agree with this distinction. The term is confusing. And I’ve never understood how you get finer grained authorization with the additional abstract layer of “entitlements.” You already have roles, groups, and permissions. I have always felt more comfortable thinking of these terms in the vein of Role Based Access Control (RBAC).

But there is a more fundamental reason why I don’t like the term Entitlement Management. Users have entitlements…or permissions, privileges, groups, roles. And I believe thinking about the user as the center of fine-grained authorization limits fine-grained functionality. Rather than thinking about users, if fine-grained authorization is the requirement, the focus should be on the protected resource.

The protected resource (fronted by a PEP) could be a Web Service, Web Application, Portal, Database, LDAP Directory, Legacy System, etc.  Each of these resources then have associated actions (e.g, CRUD). A policy for an action upon a resource defines the attributes of users, services, resource metadata, environmental or transaction-specific, etc.  that must be present at the time of the authorization decision.  This architecture has been defined by the Department of Defense (DoD), with help of vendors like Jericho Systems, as Attribute Based Access Control (ABAC).  ABAC is an access control architecture that an enterprise can implement when traditional RBAC does not suffice.

I might be mistaken, but I don’t think any organization set out to management entitlements.  They are looking for fine-grained authorization.  What I would like to see more work on is the trade-offs between RBAC and ABAC.  (A shout out there to Burton Group !)  When should you use one over the other?  If compliance is your business driver for fined-grained authorization, then maybe RBAC suffices.  If saving lives or killing bad guys is the requirement, can you do it with roles and role management or do you need an ABAC approach?  And somebody needs to cover the additional complexity that XACML policy brings to bear, including best practices for policy management, including configuration management issues.

My gut is that much of corporate America will do fine with coarser grained access control methodologies for a while…but in DoD, the Intelligence Community, Healthcare, and in the coming Cloud looking at finer-grained authorization methodologies is required.