My blog has moved and can now be found at http://blog.aniljohn.com

No action is needed on your part if you are already subscribed to this blog via e-mail or its syndication feed.

Sunday, September 28, 2008
« Information Disclosure Threats and Web S... | Main | Reality of XACML PEP-PDP Interoperabilit... »

What is the current state of interoperability between XACML PEPs and PDPs from different vendors? I am currently looking to see if there is a consistent implementation of PDP interfaces among the multiple Fine Grained Authorization/Entitlement vendors such that I can point a XACML PEP from one vendor to the XACML PDP of multiple vendors and not have to do custom integration to make it work.

Back in February 2007, Burton Group issued a challenge to the the industry to demonstrate interoperability of XACML. Some of the questions they asked were "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?"

The industry responded, via the OASIS XACML TC, in June 2007 by having the first XACML Interoperability Demo at the Burton Group Catalyst conference. There were two particular use cases in this demo, which required interoperability between vendor implementations of PEPs, PDPs and PAPs:

  • Authorization Decision Request/Response
  • Policy Exchange

I am particularly interested in the first scenario and in looking at the interop scenario document, it would appear that some specific choices were made in order to make this work:

  • Implementation of the XACML Interface of the PDP as a SOAP Interface which accepts a XACMLAuthzDecisionQuery and returns a XACMLAuthzDecisionStatement which are contained in the SOAP body.
  • Use of the SAML 2.0 Profile for XACML 2.0 which defines a Request/Response mechanism for carrying xacml-context:Request and xacml-context:Response elements.

In effect, what you ended up with in order to make this work is the implementation of a standardized SOAP interface that adhered to the following Request/Response (Taken from the interop scenario document):

Sample SOAP SAML XACML Request wrapper:

 SOAP_XACML_Request

Sample SOAP SAML XACML Response wrapper:

 SOAP_XACML_Response

I attended this event and remember coming away impressed at the results while simultaneously amused at some of the coding heroics of the vendors who, if I remember correctly, in some cases had very short time frames to work with.

It has now been more than a year since this interop event and at this point I have a very simple question for the vendors in this space "Who among you actually implement this interoperable interface specification in your current shipping product?"

From what I see to date (and I am more than happy to be corrected on this point) is that while many vendors claim conformance and implementation of the XACML 2.0 standard, their PDP interfaces are still proprietary and unique. Oh, don't get me wrong, these interfaces may be implemented using web services etc. BUT each web service implementation is unique and special to that vendor and does not follow any consistent interface specification and as such is an integration exercise that is left up to implementers if you have PEPs from multiple vendors. e.g. XML Security Gateways or Software PEPs from multiple vendors which need to talk to a XACML PDP.

del.icio.us Tags: ,,,

Technorati Tags: ,,,
Tags:: Security
9/28/2008 12:11 AM Eastern Daylight Time  |  Comments [0]  |  Disclaimer  |  Permalink   
Comments are closed.