XACML, transports, crypto, and management – a dev’s view
Travis Spencer (@travisspencer) with whom my colleague Gerry (@ggebel) and I have had chats over the past few months, recently published an interesting article on XACML, its shortcomings, and the possible solutions. Travis structured his ideas around 3 main points:
- transport / communication protocols,
- trust, and
Following this, Gerry had a bit of chat with our folks in Sweden (@axiomatics) and came up with a response which you can read on his blog.
I wanted to take a few minutes to look back at the challenges from a developer’s / architect’s perspective. It’s worth remembering that XACML define 3 particular areas:
- the policy language;
- the request / response protocol; and
- the architecture.
A XACML request by any other protocol would be as sweet
In his first point, Travis regrets there aren’t any further wire protocol definitions. When I asked the editor of the XACML specification, Erik Rissanen, he replied XACML should focus on what it does best and not focus on communication protocols. And to some extent I agree. XACML decided to focus on how a question is asked e.g. how to write in XACML “Can Bob eat ice cream?” As a developer, this brings ease of use. This means that – with an adequate XACML request / response API (we usually call that the PEP API) – we can quickly integrate authorization capabilities in pretty much any architecture (see Gerry’s post on the ‘Anywhere Architecture‘). If XACML, on the other hand, specified within the core of the standard how to bind a question to a transport protocol, that would force developers and architects to adopt that transport. This would seriously restrict the applicability of XACML.
To better address the lack of wire protocol specification, the XACML folks put in an X into the acronym XACML. X stands for eXtensible. This means anyone is free to write an extension to the language, called a profile, to specify a particular area / domain. Profiles can deal with communication protocols e.g. the SAML 2.0 binding of XACML 2 .0 or it can deal with usage models of XACML e.g. the RBAC profile for XACML. Having the ability to define and use any number of profiles not only addresses the lack of communication specification in the core but also brings architects more freedom.
In addition, rather than focusing on wire protocols, XACML focuses on the different ways of expressing XACML requests. It’s a bit like Shakespeare not worrying so much about the paper he’s writing on but thinking twice about what Hamlet will be next. This comes straight from another profile – the Multiple Decision Profile. I will be posting about those later this month.
In short, lack of communication protocol binding means the freedom to integrate with anything, be it JMS, SOAP, REST, or a standard as yet not invented.
To trust or not to trust the source of attributes…
In the second point, Travis suggests we should cryptographically bind attributes to a trusted IDP. This is, presumably, to augment the trustworthiness of the attributes. It is an interesting point but quite often either not practical or an indirect consequence of the architecture.
Let me explain. There are 2 possible ways a PDP can retrieve attributes: via the original request sent from the PEP to the PDP and via attribute lookup from within the PDP itself. The PDP has no choice but to trust what the PEP sends. Even if the PEP were lying, it wouldn’t really matter because ultimately the PEP is the one enforcing the decision. If the PEP can send false attributes then what prevents it from not enforcing a DENY or a PERMIT?
More pragmatically, let’s think about sources of attributes. Typically they will come from the company LDAP or perhaps a UDDI. More often than not, these sources of information will be protected by means of a username / password for instance. There is therefore a point-to-point trust relationship between the requestor (PEP or PDP) and the provider (the LDAP).
As a matter of fact, having sources of attributes protected can lead to interesting scenarios. A short while ago I worked on an Axiomatics – Radiant Logic integration. Radiant Logic is a leading virtual directory provider. My counterpart there was telling me that the VDS product they offer can filter out attributes before returning them to the requestor based on the identity of the person logging in.
Example: an employee can have attributes that relate to his job, his personal information, his HR information, his ratings. A project manager would only be able to query job-related attributes for that employee. VDS can filter those out.
Gerry also mentions federations. A former colleague of mine, Theo Dimitrakos, has long been researching in the area of trust and SOA. He led an EU project, TrustCoM, on precisely the topic of trust and federations. In that project, 2 or more companies could join together in a circle of trust (or federation) and exchange users & services. In that case, attributes were sent from one enterprise to another by means of SAML assertions. Not only did the SAML assertion represent a given user’s constrained virtual identity within the circle of trust, but it also carried that user’s claims. The SAML assertion contained ‘plain old’ XACML. The receiving PDP could be sure the attributes came from a partner site.
However this poses another question – that of the semantics of attributes. How can we agree how to express a given user’s or resource’s attributes. For a car, for instance, should we talk about color or body-color. Is it grey or gray? Is it a String, an Integer, or a specific type?
In short, look at the relationship between PEP/PDP and sources of attributes. Do not shift the trust challenge from one point to another.
Be not afraid of XACML policy management tools: some are born small and simple, some achieve completeness…
Lastly, and rightly I might add, Travis stressed that the management of XACML policies isn’t quite a stroll down the park yet. True, or if it is, it’s probably quite a hike somewhere in the Norwegian fjords. Great views, well worth the effort, but not something anyone can do. But again, the XACML folks thought about that issue. The standard promotes a well-decoupled architecture inherited from RFC 2904 (AAA Authorization Framework) which defines (amongst other things) a Policy Administration Point through which management can take place. This – again – means that products can make APIs available for custom, possibly programmatic, possibly manual, possibly remote management.
Axiomatics’s APS comes with such an API and customers are welcome to develop their own apps that can write simpler policies and push them. As a matter of fact, before I joined Axiomatics, I had done just that. I had designed and implemented a web-based ‘governance gateway’: it could remotely manage XACML policies jointly with XML gateway policies (WS-Policy) and user identities (key pairs and SAML generation processes). The results were delivered within the BEinGRID project.
Such stuff as (IAM) dreams are made on
XACML is a great language. It’s flexible enough that you can express many scenarios and it opens many doors for extensions and cool new apps. Sky’s the limit!
Thanks to my colleagues at Axiomatics, to Gerry, and of course Travis! And I shouldn’t forget William Shakespeare who kindly donated his prose (and verse) for the headlines.
Thanks, David, for continuing our conversation about XACML here on your blog. You raised some good points, and gave me a lot to munch on. I look forward to future discussions like this one both here in cyberspace and in person.
Hi David, wrt different wire protocols for PEP/PDP interactions, do you know of any work for a REST API?
Hi there Paul,
We are not currently developing any REST API at Axiomatics. However considering the architecture, it would be fairly simple to do so. As a matter of fact, one of our developers just finished a CXF+Tomcat PDP wrapper and along with it a CXF PEP. But that still uses SOAP & WS-Security. Is REST something you are interested in particularly? What’s the rationale? Efficiency?