Building an Entitlements Management Solution

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

David Garrison's Blog | April 3, 2008   9:47 AM | Comments (0)

So what does it take to build an Entitlements Management solution? That depends on who you ask of course. However, when I look at commercial products in this area I see certain common architectural patterns. Many of the products that I’ve seen (including our own) make use of a set of common elements defined by the OASIS XACML standard (eXtensible Access Control Markup Language).

The picture below shows the typical components of an Entitlements Management solution. The XACML spec defines the role of the Policy Administration Point (PAP), the Policy Decision Point (PDP), the Policy Enforcement Point (PEP), and the Policy Information Points (PIP).

The Policy Administration Point (PAP) manages the creation and storage of policy data in the Policy Store. The administrator interacts with the PAP (typically) through a browser based management console where roles, policies, resources, actions and so forth are defined and managed. The policy store may be an LDAP directory or a database. The PAP may also provide facilities for policy import and export. Most products provide some management APIs that allow customers to embed administrative functionality into their own applications.

Runtime role or authorization decisions are determine at the Policy Decision Points. Typically I’ve seen two ways that PDPs are deployed:

• As a centralized entitlements server that can be invoked by remote clients via RMI, Web Service calls or using the XACML 2.0 request/response protocol.
• As an embedded PDP deployed in same process space as the application. The most common examples are PDPs embedded in a JVM for plain Java applications or embedded in an application server for J2EE applications.

The PDPs can be configured to get data from one or more Policy Information Points (PIPs). These PIPs can be user or application directories or databases that contain information that is required to make an access decision. Such information includes user, group, and resource attributes (e.g. user profile information, account balances and limits, etc.). These attributes can then be used in the policies which control access.

Most entitlements products that I’ve run across cache policy at the PDP so that the PDP can run independent of the PAP. But that means that there has to be some mechanism for the policy to get from the policy store to the PDPs. The two most common ways are to push the policies from the PAP or to have the PDPs poll the Policy Database. In the first model, the administrator takes an action in the management console that tells the PAP to distribute policies to the PDP. In more sophisticated systems, the administrator can control over which policies get pushed and to which PDPs. In the other model, the PDPs periodically poll the policy database to see if their policies have been changed. Personally, I prefer the push model because it gives the administrator more control over how and when the PDPs get updated.

The last thing I’ll mention is the little blue boxes in the picture above labeled “Security Services”. This is a security framework that provides a set of security services for more than just authorization. We provide such a security framework in our AquaLogic Enterprise Security (ALES) product. The ALES security framework provides services for authenticating a user, evaluating role and authorization policy, auditing, and consuming and producing security tokens of various types. Having this framework as part of the PDP is a very powerful feature for two reasons. It provides a complete set of security services for an application and it serves as an integration platform for other security products that may already be present in an enterprise – Web SSO, identity management, user provisioning, role management, etc.

More about the value of the Security Services framework in an upcoming post.

Comments