The OASIS XACML TC is currently updating the “SAML 2.0 Profile of XACML” to Version 2.0 and seeking public comments. This is a good thing!
There are many pieces to this Profile, but to me, the two most relevant are:
- Using the standard
and to give a PDP (or a PEP) the ability to query and retrieve attributes from a [SAML 2.0 compliant attribute provider](https://blog.aniljohn.com/2011/08/ficam-backend-attribute-exchange-v2.html).
- Using the SAML 2.0 Assertion and Protocol mechanism to define a standardized, profiled, multi-platform and multi-language supported mechanism for how a XACML Policy Enforcement Point (PEP) can request an authorization decision from a XACML Policy Decision Point (PDP), and how that PDP can respond with the decision to the PEP.
(1) is something that is critically important to support, at the PDP, for cross-organizational attribute retrieval for Attribute Based Access Control (ABAC). I have spoken about this before, so won’t belabor the point again.
The importance of (2) was part of a disturbance in the tweet-force initiated by Paul Madsen and Ian Glazer last week that brought out what I believe is the primary use case for this section of the profile; Interoperability in XACML PEP/PDP communications across vendor solutions.
I’ve written about both the need for this, as well as the vendor support in the past (Reality of XACML PEP-PDP Interoperability - Part I, Reality of XACML PEP-PDP Interoperability - Part II) so won’t duplicate the reasoning here. But it is worthwhile to note some of the standardization pieces in the profile:
As you can see above, SAML 2.0 is leveraged in this profile for XACML PEP/PDP communications in two ways:
- It defines a new SAML 2.0 extension element to the
called the that can be used _"... by a PEP to submit an XACML Request Context, along with other optional information, as a SAML protocol query to an XACML Context Handler"_
- It defines how the standard SAML 2.0 _“…
containing a XACMLAuthzDecision Assertion MUST be used by an XACML Context Handler as the response to an . An instance of such a element is called an XACMLAuthzDecision Response in this Profile"_
The promise of this work will only be fulfilled by the adoption of this profile by XACML PDP Vendors, XML Security Gateway Vendors that act as XACML PEPs, COTS Application vendors who build in hooks in their applications to externalize authorization, and Physical Access Control (PACS) vendors who would like to integrate policy driven enforcement into their product lines.
Now is the time for Enterprises, and solution providers to Enterprises, to point their vendors to this work and start incorporating this into your RFIs and RFPs going forward.
- Reality of XACML PEP-PDP Interoperability - Part I
- Reality of XACML PEP-PDP Interoperability - Part II
- Converging Logical and Physical Access Control via XACML
Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!
This blog post first appeared on Anil John | Blog (https://blog.aniljohn.com). The opinions expressed here are my own and do not represent my employer’s view in any way.