Monday, January 02, 2006

XACML : Where are you!!

I do not like writing two blog entries in one day because writing each entry is very gruesome task for me (because for some reason what should be a simple memory/thought dump becomes 1 hr multi-review process to ensure my dump does not stink :) ). But, after running in to entry from James McGovern on my favourite subject of fine grained access control, I think I will write another dump.
The basic point being raised in the article are
  • What about XACML ? A question for Vendors and Analysts.
  • Implementation Patterns for opensource - Authorization Provider and Role Mappers with central management (just like an cross-cutting service in an enterprise - My addition to James' thought)
  • end-to-end (including database) Identity tracking (if I have understood the requirements properly)
I will try to put down my understanding on these subjects.
  • What about XACML? - Well it seems like people like James (and other enterprise architects that I have met in other financial institutions) and vendors like Securent (I have interacted with these guys and I think they "get it") are keeping the XACML alive. Most of the enterprise groups that are looking for fine grained access control products expect basic implementation of XACML and expect vendor assurance on this subject. This is forcing the vendors to comeup with good analysis of XACML w.r.t. to the things that are misssing from the XACML specification (like authorization delegation). This information can be used by enterprise to force these vendors to get together and sort out the details for these sections. As long as enterprise keep their pressure and show interest, XACML will continue to grow.
    Besides that, like James has described for opensource, another policy that I have seen Architect follow is to make sure that new products that they run into (for e.g. in grid computing) are aware of IAM products and technologies and what they should be doing to ensure their product will integrate well with existing IAM technology. This in case of authorization would automatically lead them to XACML.
    One of things that really bothers me is the issue that people do not associate the authorization with a centralized management system and thus do not understand the need of standards for authorization resulting in being unaware of any standards. Besides that some of the architects approach the authorization as an extension of their business rules engine and thus miss the XACML aspect of the authorization. So, to some extend, the XACML is hurt by these mis(sing)conceptions of the architects in the enterprise.
  • Implementation Pattern in opensource - The opensource still seems to be trying to figure out the identity. Looking at the list put together by Jim Yang, we can see that opensource is still building the technologies as they need it. So, we are still looking for the Apache Server of Identity Access Management. Well incidently I did run into an initiative at Apache and was both overjoyed (that somebody is working on it) and was disheartened (I think they are on slightly wrong track [My thoughts]) after reading through the available documentation. Besides that I am of the opinion (after looking at other available stuff) that J2EE got the authorization API model wrong. This realization comes from the basic issue of how can you build a API model that is dependent a specific authorization model (in this case RBAC) when we already have had atleast three access control models (like MDAC, MAC, RBAC) that have come and gone. The basic question is "Can the user perform specific action on a resource" and not "Does the user belong to specific role". So, this is where I think we need a authorization provider (no role mapper is necessary for application!!) API which is built on XACML request/response model. Based on this understanding I would really love if opensource is able to figure it out the right way and would be more than happy to help them in what ever way I can.
  • end-to-end Identity tracking - James also raises the idea of identity enabled connection pooling. I think this points to the basic issue of end-to-end user transaction auditing, monitoring and access control. The front-end and business logic layers are mostly Identity aware (due to Web SSO) but we are completely at loss in transferring the identity to database system and other backend systems. In that regard, James approach would be a good start. But I am really looking for a complete data access control layer at this control transfer point or a standard way to transfer the identity to backend system so that they can do access control based on the identity (besides the "Run As" Identity that is used in most database application). I would really be looking forward to Access control product from Oracle and hope that it will have the ability to transfer the session identity from container to database as part of database call for authorization function or may be one of Application Server company (BEA seems to be well placed to do this with their weblogic and WLES) will release something to take care of this efficiently (i.e. with very low overhead).
So be it.

No comments: