The Mobile-Cloud Axis Needs A Modern Authorization System. XACML 3 Isn’t It

Andras Cser probed a sore spot in IAM last week with his post, “XACML Is Dead.” It’s a necessary conversation (though I did see a glint in his eye at the Forrester BT Forum after he pressed Publish!). Our Q3 2012 Identity Standards TechRadar showed that XACML has already crested the peak of its moderate success trajectory, heading for decline. We haven’t seen its business value-add or ecosystem grow since then, despite the publication of XACML 3.0 and a few other bright spots, such as Axiomatics’ recent funding round.

It’s not that we don’t need an interoperable solution for finer-grained access control. But the world’s demands for loosely coupled identity and access systems have gotten...well, more demanding. The solution needs to be friendly to open web API security and management. It needs to be friendly to mobile developers. And it most certainly needs to be prepared to tackle the hard parts of integrating authorization with truly heterogeneous cloud services and applications, where business partners aren’t just enterprise clones, but may be tiny and resource-strapped. This admittedly gets into business rather than technical challenges, but every ounce of technical friction makes success in the business realm less likely.

We know that mere coarse-grained authorization won't give us the higher-quality auditing and access governance we seek. But fine-grained authorization often becomes mired in the details of legacy apps that are least friendly to centralized authorization in the first place. What we need for progress on mobile-cloud security is scope-grained authorization -- yes, as in OAuth-style scopes. Andras mentioned OAuth as a key component for mobile use cases, and I’ve previously blogged about a “new Venn of access control for the API economy,” with the UMA protocol appearing as a key OAuth-friendly element. (Disclosure: I founded the UMA standards effort and still serve as its group chair.) With implementation and usage experience, it’s becoming clearer how the UMA model might impact access control in the post-WAM, API-enabled, mobile-friendly era. A newly published case study called “Access Management 2.0 in the Enterprise” runs through the thinking.

What about XACML’s new RESTful, JSON-friendly profiles? These are a great start, but I’ve been calling for an XACML reboot to enable greater diversity of policy evaluation engines. To those who think having three or four excellent engines is enough for the entire world, my rejoinder is: That’s what the SGML vendors said in the early 1990s. SGML worked great for government agencies and a few enterprises with a lot of money and a distinct need. Until we pared away 80% of SGML’s features to create XML, it didn’t reach the long tail, and crowdsourcing-style experimentation was impossible. A key XML design goal, championed by Tim Bray, was that a “desperate Perl hacker” should be able to construct an XML parser in less than a week. I believe this was the key that unlocked SGML’s value for untold numbers of businesses and developers -- and it’s what XACML really needs now if it wants to survive.

So what am I advocating, specifically? XACML has strengths in declarative, federated authorization policy, but needs to unlock this value for modern use cases -- and it needs to pass the smell test with exactly the developers who have already rejected XML, SOAP, and top-down governance. My sources say that even the US Department of Defense doesn’t use all of XACML’s features, so clearly it’s way too big. It needs an 80/20 refactoring (Tim Bray would say “YAGNI”) with some strict design principles, not just a direct translation into JSON. On the other hand, XACML’s request/response protocol is not terrifically differentiated, and it's also overgrown. It should look to direct OAuth profiling à la UMA for communications between policy decision and enforcement points, taking note of the cross-domain discovery, registration, and flexibility imperatives of that world -- and using strictly Zero Trust/IAM-as-an-API designs.

What do you think? Would an XACML.next that concentrates on “growing the pie” for declarative authorization policy be valuable? Would an integration of web and post-web access management help you achieve your goals? Let us know in the comments or on Twitter!

Comments

I work in healthcare, the

I work in healthcare, the same industry that forced us to use ebXML to do document exchange. Can anyone guess how they feel about XACML?