In which I examine why XACML has failed to live up to my expectations, even if it isn’t dead, which has been the topic of a massive blogosphere battle in recent weeks.

Some background

I was working with the IT R&D team at Credit Suisse when we provided seed funding[1] for Securent, which was one of the first major XACML implementations. My colleague Mark Luppi and I had come across Rajiv Gupta and Sekhar Sarukkai when we’d been looking at Web Services Management platforms as their company Confluent had made our short list. The double acquisition by Confluent by Oblix then Oracle set Rajiv free, and he came to us saying ‘I’m going to do a new startup but I don’t know what it is yet’. Mark had come to the realisation that authorization was an ongoing problem for enterprise applications, and we suggested to Rajiv that he build an entitlements service, with us providing a large application as the proof point.

My expectations

Back in March 2008 (when I was still at Credit Suisse) I wrote ‘Directories 2.0‘ in which I laid out my hopes that XACML based authorization services would become as ubiquitous as LDAP directories (particularly Active Directory).

I also at that time highlighted an issue – XACML was ‘like LDIF without LDAP’ – that it was an interchange format without an interface. It was going to be hard for people to universally adopt XACML based systems unless there was a standard way to plug into them. Luckily this was fixed the following year by the release of an open XACML API (which I wrote about in ‘A good week for identity management‘).

I’ll reflect on why my expectations were ruined toward the end of the post.

Best practices for access control

Anil Saldhana has stepped up out of the idendity community internicine warfare about XACML and written an excellent post ‘Authorization (Access Control) Best Practices‘. I’d like to go through his points in turn and offer my own perspective:

1. Know that you will need access control/authorization
   The issue that drove us back at Credit Suisse was that we saw far too many apps where access control was an afterthought. A small part of the larger problem of security being a non functional requirement that’s easy to push down the priority list whilst ‘making the application work’. Time and time again we saw development teams getting stuck with audit points (a couple of years after going into production) because authorization was inadequate. We needed a systematic approach, an enterprise scale service, and that’s why we worked with the Securent guys.
2. Externalize the access control policy processing
   The normal run of things was for apps to have authorization as a table in their database, and this usually ran into trouble around segregation of duties (and was often an administrative nightmare).
3. Understand the difference between coarse grained and fine grained authorization
   This is why I’m a big fan of threat modeling at the design stage for an application, as it makes people think about the roles of users and the access that those roles will have. If you have a threat model then it’s usually pretty obvious what granularity you’re dealing with.
4. Design for coarse grained authorization but keep the design flexible for fine grained authorization
   This particularly makes sense when the design is iterative (because you’re using agile methodologies). It may not be clear at the start that fine grained authorization is needed, but pretty much every app will need something coarse grained.
5. Know the difference between Access Control Lists and Access Control standards
   We’re generally trying not to reinvent wheels, but this point is about using new well finished wheels rather than old wobbly ones. I think this point also tends to relate more to the management of unstructured data, where underlying systems offer a cornucopia of ACL systems that could be used.
6. Adopt Rule Based Access Control : view Access Control as Rules and Attributes
   This relates back to the threat model I touched upon earlier. Roles are often the wrong unit of currency because they’re an arbitrary abstraction. Attributes are something you can be more definite about, as they can be measured or assigned.
7. Adopt REST Style Architecture when your situation demands scale and thus REST authorization standards
   This is firstly a statement that REST has won out over SOAP in the battle of WS-(Death)Star, but is more broadly about being service oriented. The underbelly of this point is that authorization services become a dependency, often a critical one, so they need to be robust, and there needs to be a coherent plan to deal with failure.
8. Understand the difference between Enforcement versus Entitlement model
   This relates very closely to my last point about dependency, and whether the entitlements system is an inline dependency or out of band.

So what went wrong?

It’s now over 5 years since I laid out my expectations, and it’s safe to say that my expectations haven’t been met. I think there are a few reasons why that happened:

• Loss of momentum
  Prior to the Cisco acquisition Securent was one of a handful of startups making the running in the authorization space. After the acquisition the Securent stopped moving forward, and the competition didn’t have to keep running to keep up. The entire segment lost momentum.
• My app, your apps
  Entitlements is more of a problem for the enterprise with thousands of apps than it is for the packaged software vendor that may only have one. We ended up with a chicken and egg situation where enterprises didn’t have the service for off the shelf packages to integrate into, and since the off the shelf packages didn’t support entitlements services there was less incentive to buy in. Active Directory had its own killer app – the Windows Desktop, which (approximately) everybody needed anyway, and once AD was there it was natural to (re)use it for other things. Fine grained services never had their killer app – adoption always had to be predicated on in house apps.
• Fine grained is a minority sport
  Many apps can get by with coarse grained authorization (point 4 above) so fine grained services find it harder to build a business case for adoption.
• In house can be good enough
  When the commercial services aren’t delivering on feature requests (because the industry lost momentum), and the problem is mostly in house apps (because off the shelf stuff is going its own way) then an in house service (that isn’t standards based) might well take hold. Once there’s a good enough in house approach the business case of a 3rd party platform becomes harder than ever to make.

Conclusion

It’s been something like 9 years since I started out on my authorization journey, and whilst the state of the art has advanced substantially, the destination I envisaged still seems almost as distant as it was at the start. XACML and systems based upon it have failed to live up to my expectations, but that doesn’t mean that they’ve failed to deliver any value. I think at this point it’s probably fair to say that the original destination will never be reached, but as with many things the journey has bourne many of its own rewards.

Notes

[1] Stupidly we didn’t take any equity – the whole thing was structured as paying for a prototype