Entitlement Management - What are we trying to solve?

It has been 3 months since my last posting and this post has been triggered by a few events. First of all there was a great gathering of Financial Services on various topics including entitlements [senasystems.com] (sorry could not find any other reference to the meeting without the marketing fluff). In addition to that securent (a vendor in entitlement space along with CA, BEA and few others) was out of stealth[internetnews.com] mode which triggered some[zdnet digital id blog] discussion[Connexitor] in the blogosphere but nothing close to what I was have been expecting (most of the people seems to be discussing the "internet identity" way too much[James McGovern] and I guess that is because it is for the people, by the people and hence discussed a lot between the people) to happen in this space. I am guessing that most of the people who are trying to solve the entitlement problem are actually trying to solve it instead of discussing about it in public or discussing with other people who are working in this space without sharing with others. Please note that this does not include James McGovern and few other evangelists that I know of in financial services.

Anyway getting back to the panel discussion, after a good discussion on the topic one of the very good question was what are trying to solve within the entitlement management space. Most of the panelist agreed that taking up centralized and standardized entitlement Administration with centralized and distributed Policy Decision Point was a good start but that it is not an end in itself. There are still use-cases that can break that model (for example applications with very large number of resources that are individually protected or complex User based ACL for users in millions) and would probably be out of scope from such systems. So, what is the solution?

The way I see it, the solution or solutions will depend upon what are the drivers for an enterprise.

For most of the financial services firms, due to the compliance being a very important, visibility is most important driver and then the next in line is control. The visibility means that there should be a way to make the entitlements within a particular system made visible to the auditors, et al. Now this can be achieved by either using the batch mode using standardized policy model (XACML is good start but does not cover everything that is needed) that I described earlier or by making the application provide a standard interface to answer the queries the auditors may have in realtime(each approach has it's own pros and cons and I need to think more about them).

On the other hand if it is the control of the entitlement model which is more important then a centralized and standardized entitlement Administration would be a good way to proceed. Now that in itself means that for each new system, you will have to translate the Admin policy model to application policy model. This policy translation can vary from being very easy for policy model which are very simplistic (for example in case of User ACL  you can just evaluate the policy model for each user and push the result to application entitlement repository) or models that are very close to standardized administration model(which hopefully is a broad model). In case of rest of the applications, the model translation may not be possible since some of the components used for modeling the policy in the administration system may be missing and there may not be any way to translate them to something that the application may understand (this can be mitigated by ensuring that the administration system model does not contain policy constructs which can not be consumed by the application).

In case the driver is getting the security model implementation out of developers hand, then the centralized/distributed Standard Decision Point (and associated policy model administration) may be the way to go or incase of standard container managed systems a Standard Enforcement Point can do the trick.

At the same time in most of the cases there are multiple drivers and so people may have multiple solutions in place to solve the problem.

Anyway what ever are the drivers and corresponding solution set that an enterprise needs or implements, the next step is to integrate with existing Identity Management infrastructure(that's for the next blog entry).

Another good obvious question was how to choose the applications for the new entitlement management platform/solution that people are building and there were some good answers esp. with regards to using the following criteria

1. New Applications are good candidate for the new platform (SOA anyone?)
2. Application that have hit wall w.r.t. entitlements and are themselves looking out at vendors to solve their problems
3. Applications with new audit requirements may be another good candidate for the platform.
4. Evolution vs. Revolution - May be I did not choose the right words but guess the discussion was around the idea of whether you should choose the most difficult/visible application (revolution) and prove the platform or make small gains with well selected non-critical applications. In addition to that most panelist agreed that a good choice could be an apps of low criticality but highly complex policy model which validates the platform and at the same time the setbacks due to initial platform gliches will not become a big mess). One of the participant suggested the idea of using usage footprint with frequency of use to identify the new application.

After you have a platform in place the next step is to evangalize the platform within the enterprise (and even outside). There was a good  discussion on how to go about doing that

• Internal Developers - Even though there was a skeptism about whether Application Developers would accept the new platform as an integral part of application development without "shoving it down their throat", it seems that many enterprise have had a good experience on that side in terms of letting the word about the platform spread through "word of mouth" based on initial success of a few applications.
• Outsourced Development - This is something that can be tackled through standard development process or letting the application architects buy into this platform. But at the same time I think some standardized APIs for Java (no JAAS is not the answer) and .NET may be a good starting point.
• Product Vendors - This is a very important field of people with whom this process needs to be repeated right now so that just like the Web SSO support has become an integral part of the development process, the vendors should have a good understanding of this domain and a well formulated strategy on externalization of policy enforcement/evaluation/administration. 
• Service Providers - This new breed of SAS is something that most people are not thinking about at the moment but may be something that becomes important (may be pushed by federation) going forward.

The session overall provided a good insight into the lack of good understanding of this space not interms of what needs to be done but what is the best way of doing things.

Please note that this post is not a news piece and contains the various concepts from different people as I understood and have been tarnished by my thoughts on the subject (which may be totally wrong).

Hope this helped.