Reality of XACML PEP-PDP Interoperability - Part II

In another context, I was recently asked:

Since you first posted your article about interoperability, did you find out “Who among you actually implement this interoperable interface specification in your current shipping product?”

Thought I’d share the relevant bits of the answer that I gave:

“… before I answer your question, please know that the focus for my environment was/is on building out a policy driven infrastructure for a web services environment. And the motivations for going down that path include:

1. Consistent enforcement of policy (and in this particular case, access control policy) across multiple services
2. Minimize the number of interception points in the message path
3. Take the burden/complexity/headache of security policy out of the hands of the development teams who are deploying the services and move it into the infrastructure

As such, what I was particularly interested in having happen is for the XML Security Gateways in my environment to act as a XACML PEP to a remote XACML PDP. So to answer your question, you need to look at both the PEP and the PDP side:

One the PEP side, the answer is “It depends” on how flexible the product is. Most of the gateways provide you some mechanism for making an external “call-out” as part of the decision making process. i.e. Incoming request comes in to the PEP; PEP intercepts, does some basic threat and malicious content scanning, Authenticates the user/entity, then formulates an AuthZ request, sends it out in an “external call-out” to a PDP, and acts on the decision when it is returned. The ease of how you can do this, and the ability to customize that call-out depends on the particular product. You basically have on one extreme the need to engage the consulting services of the vendor to customize that call, to the other of being able to have the ability to do-it yourself using nothing more than message templates. So in short, you can bend the metal to make the PEPs generate a XACMLAuthzDecisionQuery and I am aware that at least a couple of the vendors in this space have it on the roadmap to be a native XACML PEP, but I am unsure of exactly what they mean by that term.

On the PDP side, what I will say is that silence as answer to the question is an answer in itself.. :-) Pretty much all of the PDP vendors have some sort of a web service interface to their “Authorization Service”. To date my experience working with multiple products (both on the PEP and the PDP side) has been that you simply cannot point a PEP to PDPs implemented by multiple vendors and expect it to work without custom “franken-code” on either/both the PEP and PDP ends (Even though this was exactly the point of the Catalyst Demo that I noted in my blog entry).

These days my response to the vendor response of “Oh, Sure we do that!” is a request for a pointer to the WSDL and the XSDs of their Authorization/Entitlement Service of their current shipping product to prove that they indeed do it. For some reason, the conversation seems to just die out at that point …”

As always, if my understanding is incomplete or incorrect, please feel free to leave a comment on this blog entry.

Related Posts:

• Reality of XACML PEP-PDP Interoperability