Waiting on XACML: An interop challenge for the industry

Is it time for a XACML interoperability demonstration? The eXtensible Access Control Markup (XACML) standard has matured enough to be supported in a growing number of commercial identity management products. And several other vendors have put XACML support in their 2007 product plans. Version 2.0 of XACML was formally ratified in March 2005 and the OASIS technical committee is working on improvements for version 3.0. As noted in a previous post, many enterprises have embarked or are considering entitlement management projects where the authorization standard plays a significant role.

Despite the growing use of and interest in XACML, there has never been an interoperability demonstration event, and there is no formal certification or interoperability program like the one Liberty Alliance operates for the SAML 2.0 and Liberty specifications. When does this become an issue for the industry? Will the need for interoperability grow as adoption of XACML-based products increases? Can enterprises really mix and match policy administration points (PAPs), policy decision points (PDPs), and policy enforcement points (PEPs) from different vendors? Is the XACML RBAC Profile practical? Or will we find that different interpretations of the specification yield less than satisfactory levels of interoperability?

An interoperability demonstration can’t answer all of these questions, but it can provide an important indicator of the state of the market. At Burton Group, we’re fond of putting on interoperability events at our Catalyst conference – especially when they are industry firsts such as the SPML version 2.0 demo in 2006 and the multiprotocol federation event of 2005. Is it time for an XACML interoperability event? We think so and have invited vendors to come up with a game plan for the conference this year. Will they take up the challenge? They probably could use some encouragement, particularly from enterprise customers. Let them know how you feel by commenting on this post or contacting them directly.

[posted by Gerry Gebel]

Comments

[Mark O'Neill, Vordel CTO]

Here at Vordel we'd certainly welcome this initiative. As an XML Gateway vendor, we have built interoperability with many authorization products such as CA/Netegrity SiteMinder, IBM Tivoli Access Manager, Entrust GetAccess, etc etc etc.

In many cases this interoperability involved the use of APIs rather than the use of the XACML PEP/PDP model. If XACML was used in a standard manner across the board, then that would have helped us a lot. As it stands, we built all the connections anyway, but we still expose a XACML PEP/PDP interface ourselves so that our customers can take advantage of this.

I've written about Vordel's XACML PEP/PDP support and experiences here:

http://radio.weblogs.com/0111797/2007/01/22.html#a73

cheers
-Mark

[Kari-Pekka Lifländer]

My conclusion: XACML is a nice standard but it will never be adopted or it will remain as a marginal effort.

Our analysis:
BEA announced a couple of years ago that they will support XACML in the future of their application platform and portal products i.e. application or platform internal PEP/PDP functionality. We assessed this a little bit "on paper" and noticed immediately that this cannot work with any of the technologies known today. Reason is just purely performance. Currently the PDP decisions are done internally in the application run time and e.g. in our portal solution there are about 200 PDP's done every time the user refreshes the browser. If these would move to XML based communication then the performance would be deteriorated enormously. And the fact is that we already doing the everything with business and access role using enterprise LDAP as the source for the role data. With fine grained rights management existing using centralized directories AND taking into account the performance hit from XACML, I have no trust in XACML. What would be the added value of it compared to centralized roles management and the fact that practically all current business applications available in the markets today do support external directories? It's hard for me to find any...

[Ed]

" If these would move to XML based communication then the performance would be deteriorated enormously. "

This is boloney. Nothing in XACML implies that you need to go to XML based communications. It is protocol independent and a good implementation should optimize policy language properly. Sorry, you do not understand what you are talking about.

[Sampo Kellomäki]

Both XACML and LDAP approaches have their place and neither one will fully displace the other. We see XACML being preferred solution for loosely coupled systems while LDAP is still the performance king for intranet and tightly coupled systems. Rather than focusing on inefficiency of the XML transport, real scalability comes from proper caching and even prediction of PDP queries. Or from choosing correct trade-off point on granularity vs. performance axis for your authorization decision queries. These are the solutions we support in our products.