There’s a little bit of a kerfuffle going on in XACML-land. A non-Gartner analyst made the claim that XACML is dead. Such a claim doesn’t go unnoticed; so Gerry, Anil, Danny, and Remon have all responded that no, XACML isn’t dead. It is not pining for the fjords. It isn’t even zombified.
Anyone can declare a protocol dead. Last year it was SAML. This year, apparently, it’s XACML. Now as someone who killed off the entire IAM industry, I think I’m in a position to comment about this.
It’s easy to say X is dead. SAML, SPML, DSML – doesn’t matter – you declare it dead, write your blog post, and call it a day. But what’s hard to do, and what is necessary to do, is, if you kill something off, you have to offer an alternative. In the case of IAM, I believe we are seeing the hazy outline of what it will become reborn as start to emerge: something more nimble, developer-friendly, and more indistinguishable from business services. In the case of XAMCL, no alternative was provided.
Just a few things to keep in perspective when thinking about XACML. First, separate externalized authorization management (EAM) from XACML. Enterprises have been doing EAM for decades. The pattern of using something like RACF as a decision-as-a-service facility is a well established practice. Although enterprises may not be using XACML, they are doing EAM and that will only continue.
Second, EAM vendors recognize that they need to increase the number of places where they can provide authorization enforcement. To this end, we see more out-of-the-box PEPs than ever. More importantly, we see EAM vendors team with federation and WAM vendors to offer the rich policy capabilities of XACML paired with traditional, already deployed, enforcement points. That is a huge deal. In fact, my colleague Gregg, predicts that by 2016 80% of fine-grained access control requirements will be met in this manner.
Third, XACML as a system-neutral policy language is an important concept. The ability to translate XACML into local policy languages and thus enable applications that aren’t EAM-aware is key to EAM and XACML’s future. We are seeing this begin to happen in more meaningful ways – such as some vendors’ abilities to translate XACML into SDDL for Windows Dynamic Access Control.
Finally, the standards community has been active too – work on JSON bindings for XACML as well as RESTful bindings will further XACML’s adoption. In addition to this, the OpenAZ project continues to move forward providing a vendor-independent PEP API that anyone can use.
Speaking of standards. Come to Catalyst this year. Hear representatives of the standards themselves why they are relevant and how they can be best put to use doing real work. I’ve arranges a standards smackdown. Come here some industry luminaries represent popular identity standards:
- SAML – represented by Pat Patterson
- OAuth – represented by Paul Madsen
- SCIM – represented by Kelly Grizzle
- XACML – represented by David Brossard
- OpenID Connect – represented by Pam Dingle
Also, I’ll be picking up the ‘Killing IAM’ theme and talking about more about how we as an industry move IAM into the modern era. See you in San Diego.
Read Complimentary Relevant Research
Predicts 2017: Artificial Intelligence
Artificial intelligence is changing the way in which organizations innovate and communicate their processes, products and services. Practical...
View Relevant Webinars
The Mobile Scenario: Taking Mobility to the Next Level
The definition of "mobile" in the post-app era will involve new interactions such as bots and conversations, new devices such as wearables...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.