Entitlement Management: More than meets the eye

Ian Yip just blogged his thoughts about what Entitlement Management means. It’s interesting to hear his take, because not too long ago, I participated in another discussion that was trying to define EM. Back then, the contention was that entitlement management and RBAC were essentially solutions to the same problem, setting off a “which one do I need” debate in the consumers mind. I’m not going to go into the details here, but in that post I did lay out the key point that roles and entitlements are both complementary abstractions meant to solve the fine-grained access problem.

As an abstract identity construct, entitlements model whatever it is in an actual system that allows a user to do some well defined thing. As such, it is a fine-grained access management construct, so Ian isn’t wrong about that. But I think Ian’s post misses the power of the entitlement construct, which is what entitlement management products aim to surface.

An entitlement could simply be the permission to access a URL (typical web access management scenario). It could be the permission to click on a menu item in an application (typical application functional security scenario). It could be the permission to access a particular data record in the database (typical data security scenario). Each of these taken individually is a pretty big deal in of itself, but can be handled by products or features that are already available today.

But in a service-oriented world, where multiple applications get chained together to perform the functions behind a single action a user can perform, the entitlement becomes a hugely important construct. Currently, this would require ensuring that the permissions within every single component are properly coordinated to allow this flow to go off without a hitch. It becomes a very complicated permission engineering problem to figure out how the ensure that the function will work in all cases necessary.

Entitlements provides an abstraction and layer of indirection that eases the problem, unifying the access control equation. In an entitlement management based architecture each service, every tier within the service, every layer within the application, can refer back to the same entitlement and entitlement policy to determine whether or not to allow the function to proceed.

And to provide this kind of cross-service access control, an Entitlement Management product like Oracle Entitlements Server provides the ability to define powerful entitlement policies based on identity, role and contextual data. And while XACML is a necessary part of the architecture that enables a complex deployment to occur, it is just an enabling tool, not what defines the feature itself. In fact, XACML does bring its own limitations to a run-time environment.

Entitlement Management is a powerful tool that can simplify the mess of permissions and privileges that are strewn all over the enterprise landscape. When applications were silos, it was sufficient to deploy a provisioning system that could handle the provisioning of access into these black boxes. But with applications transforming into services and becoming increasingly interconnected and interdependent, role and entitlement management become critical pieces of enterprise architecture that help provide critical control, predictability and uniformity to the enterprise.