It's the authorisation, stupid!

As the US presidential election is in full swing, I thought it would be a great time to dust off Bill Clinton's catchy statement from way back when and seize it for my own agenda. As the industry is increasingly focused on the identity metasystem that will delivering identity to applications, and much attention is given to strong authentication, I believe that authorisation is a very much neglected topic. Very unfortunately so.

It appears as if many of us have just about accepted the fact that authorisation is the domain of applications. Large enterprise software suites typically implement their own security infrastructure. Some others outsource this to the underlying operating system, most notably Microsoft Windows. We seem to be content to deliver identity data into applications, and letting them take care of deciding who gets access to what. This I find dangerous, and going down a very wrong path in the long run. Let me explain why.

Doing it over and over again. Is your organisation building custom apps? Every application developer of a custom-built application has to implement access control and authorisation yet again. Most developers are really not that savvy or even passionate about security. After all, software development is mostly about finding new ways to do things, not so much about restricting one to do things (unless you're writing security software, of course). I find it very scary that in many organisations, access control has been implemented differently many times, by many different teams. How can you be sure that everybody got it right? What's the sum of all bugs in all of the authorisation code? How much time and money has been spent reinventing and rewriting the same wheel over and over again?

What access management? Controlling access is done in very segregated approaches. It's not uncommon to find multiple identity "universes" next to each other in isolation. We have managed to apply band-aid to the "identity wound" of having disconnected pieces of identities in different stores through provisioning systems and virtual directories. But the "authorisation wound" is untreated and oozing. Yes, there are a variety of "access managers" and "SOA security" solutions out there. Do they really solve the problem? No, because usually they are too coarsely grained, and therefore only relieve some of the symptoms of weak application security without really curing the underlying problem.

Sleepless nights at audit time? Regulations are getting tougher, and audits are taking much more time and money. Once central security services were in place, their mechanisms would need to be scrutinised just once, and after that it's just about auditing their use inside the applications. At this time role management software is touted to be the magic bullet, albeit in the form of another band-aid to the "authorisation wound" (as described in the next paragraph).

Incompatible entitlement systems. We are seeing a growth in GRC (Governance, Risk-Management and Compliance) tools that build data warehouses of entitlement information, and then try to make sense of the whole mess. Those entitlements are usually completely different in structure and interpretation, and trying to distill this hodgepodge into higher level business roles is a daunting task that needs continuous readjustments. True, the tools offered by the vendors in this space are getting better and better. But effectively the aim is to bring some order into chaos - to fight the never-ending battle against entropy. On the other hand - just think about it - even if only 50% of the authorisation could be derived from business processes, business roles and other high-level information, that's already 50% less entitlements that would need to be managed.

Lack of vision and/or willingness of the industry to cooperate. Barring some notable exceptions, the large vendors don't have a vision for solving authorisation systematically, or are keeping their cards very close to the chest. Oracle is one of the exceptions here, with a mission statement that this is important and needs to be solved. Other vendors have ad-hoc solutions for offering fine-grained authorisation for custom applications, mostly in the form of embeddable entitlement "managers" or agents. Some are having a field day bashing the XACML standard, and whilst they are right in that it does not solve all problems, it certainly addresses quite a few of them. Hey, SAML does not by itself fully secure your web services, but it certainly does its part in the effort. My word processor does not write my reports by itself, but it certainly helps me getting them done.

Service oriented What? In a brave new SOA world, applications are no longer monolithic, but comprised of many services interacting with each other. Identity and access control is an important part of this. Whilst this year has brought us much further in the Identity field with WS-* on the path of becoming mainstream, authorisation is not just a large and ugly pothole on that road, it's a crater. Unless the industry comes together to adopt an interoperable, standards-based approach to access control,

What now? I may be painting a bleak picture, but it's not all bad. Several small companies are taking the lead right now to create enterprise-wide access management technology, driven by compliance requirements. Larger vendors are certainly mulling their options. But it's the time for us in the industry to get cracking, and come up with the methodologies, standards, services, protocols and APIs to solve this once and for all. Until this is done, IT won't really be dynamic, and many SOA benefits will remain elusive to most of us.



KuppingerCole Select

Register now for KuppingerCole Select and get your free 30-day access to a great selection of KuppingerCole research materials and to live trainings.

Stay Connected

KuppingerCole on social media

Subscribe to our Podcasts

KuppingerCole Podcasts - listen anywhere


How can we help you

Send an inquiry

Call Us +49 211 2370770

Mo – Fr 8:00 – 17:00