This is Felix Gaehtgens and I am one of the latest additions to the Axiomatics team. My colleagues Gerry Gebel and David Brossard were so nice to offer me a space on their blogs. As a former industry analyst, I’m going to start here, and post my future more technical musings on David’s blog.
Speaking about musings, I just stumbled upon an article on heise.de from my former colleague Martin Kuppinger. The article talks about access management with the XACML standard and is entitled “Only good if you can’t see any of it”. It is published in German, and if you can understand that, you can read it here. Martin is a distinguished and very smart analyst, and I am honoured to have worked alongside him for more than three years at Kuppinger Cole where I covered the authorization field and in particular the XACML technology. His past and current musings – apart from this one article – provide an excellent insight into the current state of technology within the Identity and Access management field.
In his article, Martin wrote that XACML is a complex language. He expects that companies implementing XACML will have to confront a large set of many complex rules, and therefore the management of these rules is complex. He makes the point that XACML has to be “hidden” by tools because it is just too complex to use.
To my experience, nothing is further from the truth. This merely reflects some common misconceptions about XACML, and it also reflects some FUD (fear, uncertainty and doubt) floating around by some people without sufficient understanding of the XACML technology. What is important here is that customers need to have fully-fledged XACML tools to solve their complex authorization problems. Cutting corners and then calling those limited features “simplification” to make it “more user-friendly” mean that you don’t get all of the powerful benefits, and shouldn’t be an option for you. You need the potential of this technology to tackle the hard authorization problems in the real world. You will need to use the concepts of XACML to create compact and adequate policies. No short-cuts are recommended here.
XACML is a language used for access control, and it is very powerful and flexible. When I compare it to simple rules used in traditional SSO and RBAC-like access management products, I like saying that RBAC is like a simple text editor and XACML is like a word processor. If your needs are really simple then perhaps a text editor is enough. But if you want to create real documents, I’d highly recommend using a word processor.
The reality in XACML implementations is that you create a small set of policies that quite accurately reflects the overall business requirements. In many cases, you can almost “translate” a business access control requirement into one policy. This makes things quite simple, because you can easily edit the few number of policies to make sure that they accurately reflect what the business is demanding.
I’ve seen this already “at work” with several of our customers. They are really enthusiastic about the fact that they can create a fairly simple policy model in XACML to link their business policies together with data that already exists in the enterprise and deploy truly powerful and dynamic access control for their applications. It’s very cool to see this in action. That’s why I really disagree about the “good practise” of “generating” XACML from “simple” rules. Sure, you can do that, and there may be some cases when this could be useful, but then you are really missing out on those benefits of XACML that can truly transform your deployment.
Consider the other, more “traditionalist” approach. You have primitive and “simplified” access control rules, often in the form of “if user X has role Y”. You then need to model your business requirements in these types of low-level rules. Not an easy task, and it also means that you will need to maintain a whole new data repository to support your simplistic policy model. That is complex. And that is much more difficult to maintain and audit.
So XACML is “expressive” and “complete” rather than “primitive” because it allows you to do many more things. It allows you to define your access policy in just a few well-defined rules that are not difficult to understand, rather than in a myriad patchwork of primitive access control statements that become difficult and expensive to maintain and audit. This in my opinion is one of the greatest benefits of XACML. Maintaining you access control system in XACML makes it much easier, rather than more complex.
When I started at Axiomatics, I already expected that our customers would find it easier modeling their access control requirements with XACML rather than using a traditional role-based approach. Once I started talking to them, I was somewhat surprised to find out that many of them found it even easier than I thought! Sure, you have to learn a little (not too much), but this usually saves you so much more time and money because if elegantly side-steps a lot of the mess that you would otherwise have to confront.
Where Martin does have has a point is that XACML is based on XML, and nobody (except maybe for some hard-core geeks) would like to maintain XACML policies by editing raw XML files. But that’s obvious. At Axiomatics, we ship a GUI (graphical user interface) that allows you to define and test your XACML policies. It offers the full power and features of XACML in an easy way, rather than a limited “simplified” subset of possibilities that don’t go far. The learning curve with XACML is not steep, because it is actually very natural in the way that it allows you to express your requirements; and as with any powerful tool you’d be advised to take a bit of time to learn about the features at your disposal and real-life good practises that we’ve learned from our customers’ experiences. I’d be happy to discuss them with you – just drop me an email.
Analyzing Identity 