My recent experience with openSSO entitlement services
Over the last ~5 years the (Application) Access Management (AM) space has gained a level of acceptance across the Fortune 500 by implementing:
- Single Sign On (SSO) – thus reducing the number of logins and passwords
- Coarse Gained Access control – enforcing policies which guard end-user entry into application(s)
To date, most enterprise deployments of AM have achieved the above through the use of proprietary policy languages and high-level roles or groups to enforce access control. Also (for many reasons), there has not been deep access control integration with these applications, thus not exposing application entitlements to the enterprise. See figure 1 – as a typical Access Management deployment.
Enter XAMCL. The next level of Access Management. It should allow customers to:
1) reuse policies across applications 2) create policies using application entitlements 3) use a standards based policy language 4) author complex polices outside AM system
The following blog details a customer scenario where we used OpenSSO 8.1 to prototype a set of use cases. Oracle also has an entitlements product, but it’s separate from their Access Management implementation.
The customer mentioned they were currently investigating solutions to replace their home-grown application entitlement system(s) with an off the shelf product from a reliable vendor. They also mentioned they were having issues with slow response time from their web access management system.
Since the customer had not yet selected a solution I recommended Sun’s OpenSSO. I explained some of the OpenSSO 8.1’s product features such as a new policy engine, entitlement services and export/import of policies. The features were interesting to the customer and warranted a demo with 1 or 2 use cases. See figure 2 – as a different approach to expose application entitlements.
The demo with OpenSSO would entail the following:
Use case: A manager employee is authorized to pay the vendors a limit of $5,000 per transaction on Thursday and Friday and between 9:00 AM to 5:00 PM only.
A VMware demo was quickly created with the following components:
- OpenSolaris 2009.06
- OpenSSO Express 9 nightly build
- Java 1.6 U17
- MySQL 5.1.42
- Sun Web Server 7.1 U7
- Glassfish Application Server 2.1.1
- DSEE 7.0
This use case was executed without any major issues using OpenSSO’s new beta console (see screenshots below). The customer was very impressed with the quality and ease of use of the new beta console. The demo also highlighted how simple it is to export / import the XACML based policies using an easy-to-use admin interface (screens attached).
OpenSSO 8.1 introduces new entitlement services based on the XACML policy language. This language provides centralized policy management, rule based policy evaluation, policy delegation, policy versioning and auditing capabilities. The major components in the OpenSSO entitlements consists of Policy Administration Point (PAP), Policy Decision Point (PDP), Policy Information Point (PIP) and Policy Enforcement Point (PEP). You can read all about XACML by visiting Oasis website.
See figure 3 – as the high level topology used in this prototype
From a deployment perspective, the customer was happy to see that the web access management and fine-grained authorization can be packaged together (single WAR file) with the application. They were also excited to see the use-case II (see figure 3) where the PDP and PEP can co-exist within the application (eg: Portal Server). This use-case improves overall portal access performance because 1) the PEP interacts with PDP locally thereby reducing the network calls. 2) The PDP can be configured to cache the policies or enable notifications in order to obtain the policy updates from the PAP. I will provide the steps about this use case in my next blog, going into more detail.
Screen Shots: Here are some of the screen shots from the POC.
Conclusion: Using this new architecture the customer was able to combine the existing identities from the Access Management solution with the application entitlements. OpenSSO 8.1 was deployed seamlessly with data being fed from various application stores without actually being migrated into a single repository. The XACML policies that where created in OpenSSO used application specific entitlements and offered both coarse and fine-grained access controls to the applications.









This blog is a continuation of the evolution thread I started in my previous blog 
In this blog I’ll chat about how we in the Information Technology (IT) world have built our own evolution models, which for the most part have resulted in the creation of a better mouse trap.





