Ian Glazer from the Burton Group wrote a nice blog on having a meaningful conversation around the definition of entitlement management. Ian was responding to a blog by Ian Yip and basically states we need more specificity around entitlements in the context of access controls. I agree with Ian’s sentiment and thought I’d take some time to discuss how Sun thinks about entitlement management when it comes to access controls.
First, as Ian points out in his blog we agree that entitlement management is to vague a term and cuts across many facets of identity management including roles, provisioning, access controls and reporting. When it comes to access controls we’ve decided to refer to it as “entitlement enforcement” so that it’s clear that we are talking about the run-time enforcement of access entitlements.
Second, when we refer to entitlement enforcement we believe that we are discussing the fine-grained access controls around resources. That is, rather than protecting “doorways” or coarse-grained access we provide authorization decisions around all the “objects” within an application or resource (often referred to as fine-grained authorization). For example, a common scenario we see is in the financial services area and the need to provide entitlement enforcement around specific fields within a banking portal. For instance, a banking portal may want to provide access controls that limit the amount of money that subjects such as individuals, roles or groups can transfer. I may have the ability to transfer $1 million dollars and Ian may have the ability to transfer $5. Note that the access controls I’m talking about are not only specific to urls, but also other resources such as fields, calendars, etc.
Third, entitlement enforcement requires policy enforcement points that are easy to deploy and scalable. Sun is approaching this in two ways. 1) OpenSSO can be deployed as a policy enforcement point or 2) we will be offering a Fedlet policy enforcement point, a lightweight method for embedding policy enforcement points within applications. The key to this effort is making it lightweight and performant at the same time. Basic jist is if you have all the capabilities to implement entitlement enforcement but it isn’t repeatable and scalable in terms of deployment then it won’t be practical to implement and could hinder adoption.
Four, Sun believes that all aspects of an entitlement enforcement solution imply scale. Your policy store needs to scale. The user interface needs to scale to allow people to manage lots o’ policies and the entitlement enforcement solution needs to be performant to ensure it can handle lots and lots of authorization transactions.
Five, auditability and simulation of policies is important as well. Entitlement enforcement needs to fit in to the development process so that administrators and developers can work together to define applications, develop policies and test policies throughout development, QA, staging and production. Providing tools to do this and ensuring that admins can export policies from the entitlement solution so that they can develop error free scripts as they move from environment to environment is critical.
Six, identity services are key to entitlement enforcement. The fine-grained nature of entitlements means there is a much larger burden on developers to tie policy to a centralized system. There needs to be several options that developers can use to handle embedding entitlements in the application or container. This includes lightweight identity web services such as OAUTH/REST, standard protocols such as SAML/XACML and complete abstraction via agents. Depending on the customer, we believe you need to support multiple options. Whereas a Web 2.0 company may be very excited about REST a financial services company may be more focused on agents and completely abstracting authorization from the developer. As Gerry points out, there are many ways to do this whether it be using XACML, WS*, OAUTH, etc, etc, etc.
Finally, Sun has a unique belief that entitlement enforcement should be part of your web access management solution. This is not specific to the definition of entitlement enforcement, but rather our belief around how to pragmatically implement it. Deploying separate WAM solution and entitlement enforcement solution adds unnecessary complexity to your identity infrastructure and vastly increases the TCO. It means that organizations have multiple products to maintain and upgrade. It also means that customers will likely have multiple policy stores within their organization. From our perspective, WAM solutions were built to handle entitlement enforcement and it is a natural extension of web access management that is more likely to lead to customer adoption rather then requiring someone to license and deploy a separate component in their environment.
Our entitlement solution is currently under construction at OpenSSO.org. It will be 100% XACML based and is focused on delivering everything I’ve described above. You can currently view it via the OpenSSO source code, but we will be providing more details shortly for you to test it out. We will also be showing the new capabilities at OpenSSO Community Day 3.0 in San Francisco this weekend. Make sure to attend so you can see it and provide feedback.
Listen Now 
