Travis Spencer (@travisspencer) raised a few issues with XACML and proposed some solutions in a recent blog post. I’d like to take this opportunity to respond in the interest of continuing the conversation. Thanks to my colleagues, Erik, David (@davidjbrossard), and Ludwig for their input.
Point 1 – Lack of wire protocol definitions: The industry is limited to a single wire protocol spec at the moment, the SAML profile for XACML. It is by no means universally applicable but is useful when integrating with other vendors’ policy enforcement points (PEP). Such is the case for integration with XML security gateways. We agree that other wire protocols are needed and expect that they will emerge over time, as the market demands them. This will require a combined effort between XACML vendors and experts in the particular protocol domains of interest. Once the industry reaches a point where multiple protocol profiles are created, then formal certification and interoperability testing may also be required – similar to the SAML profile testing that occurs today. Finally, I invite you to join the TC and provide your use cases as input!
Point 2 – Cryptographically binding attributes to a trusted IDP: There are cases where a cryptographic chain can be established between the IDP and PDP – as Craig Forster described in a comment to the original post. That is, a SAML token can be passed from the PEP to the PDP and the PDP can perform signature validation. However, this doesn’t address all possible scenarios as there are many ways that attributes can reach the PDP. In federated scenarios, a token of some sort may contain attributes, but this represents only a portion of use cases. The PEP may derive attributes from a local repository and it, of course, may send environmental attributes in the access request to the PDP. The PDP may also query additional sources for necessary attributes before making an access decision. These sources could include a local LDAP directory, web service, or customer database. The PDP could also query a remote source, as defined in the Backend Attribute Exchange (BAE) profile. Therefore it may not be practical, or possible, to implement cryptographic bindings all the way to the attribute source.
It is true that the PEP and PDP operate in a trusted ecosystem – that includes the application itself as well as other infrastructure components. XACML was intentionally designed in a modular fashion to cleanly separate authorization from other IdM functions, such as authentication. Security mechanisms are implemented to secure the communication between PEP and PDP components, but there also is a certain amount of trust between the components. For example, the PDP must “trust” that the PEP will actually enforce decisions properly and carry out all obligations. The PDP must “trust” the contents of access requests from the PEP, including the attributes about the subject. In such cases where additional context is needed, the PEP can send subject attributes plus the source (issuer) of the subject attributes – it’s just another XML string.
Point 3 – Policy authoring and administration: The XACML policy language was developed to address a broad range of application scenarios and to satisfy the complex requirements of sophisticated applications. As such, XACML is a rich language and it must be, otherwise we would be debating whether it is comprehensive enough. Based on our experience at Axiomatics (@axiomatics), if you simplify the policy authoring tool – you lose some of the XACML functionality. Some clients choose to create domain-specific and simpler admin tools but these are only used after the initial set of policies has been created. A couple other observations may be helpful. First, XACML policy development takes some effort up front, but the policies are typically quite stable and do not need a lot of manipulation. Second, the more frequent activity is management of user attributes during onboarding or when the user’s status changes. Finally, we expect more domain specific policy administration tools to emerge in the future as the standard is adopted more broadly.
In summary, I thank Travis for raising points that are issues from his perspective. XACML is not perfect but then no technology is. However, the standard and products that implement it will continue to improve over time based on experiences from production deployments across many industries. We think that XACML is a very comprehensive and capable specification – and we are seeing many leading organizations choosing to deploy it already today. They recognize the value of standards-based, externalized authorization as a competitive advantage and a vast improvement from previous models.
Lastly, I invite everyone to attend our webinar on XACML and the ‘200M’ user deployment this month (October). More information on the event can be found here.
