I promised a more detailed post about this in my previous one about ERM. This is not intended to be entitlements services 1-01, but there is some necessary preamble to set the scene. Somebody probably ought to write that tutorial, as web search and WikiPedia are unusually unhelpful in this area, but that’s not going to be me (or at least not right now).

Directories 0.0 (the dark ages) – this wasn’t all that long ago. Commercial implementations of directories first came along in the late nineties, and became mainstream at the turn of the millennia. Before that we faced a world where each piece of software had its own concept of identity, and its own store of stuff that needed to be managed. This was seriously confusing for users and expensive to manage, it also meant that good security policies (e.g. password expiry and complexity) were hard if not impossible to enforce.

Directories 1.0 (the noughties) – the arrival of a central place that organisations could store user data has quietly revolutionised how software interacts with identity/security concepts. No longer do we tolerate standalone stores of user information (or worse still credentials) – we expect integration, and that expectation is met via lowest common denominator LDAP interfaces. We also have means to export/import information from one director to another via LDIF, though this usually remains the preserve of ID management wonks.

Directories 1.0 turns out to be good enough for a huge swath of use cases – things that only need ‘coarse grained’ authorisation models, where it’s sufficient to know that somebody exists in a given group. There is however trouble in paradise – not all authorisation problems turn out to be simple enough to be expressed via the coarse grained mechanism of groups. In part this has led to directory abuse, with most enterprise directories turning out to have more groups than they have people in them, but that isn’t the end of the problem. The problem that we face today is that each application or service that requires a fine grained authorisation model comes with something baked into that application or service (just like the dark ages apps had their own mini directories with just their users in them). Each piece of software like this comes with its own role mapper, its own entitlements concept, its own policy language, its own tool to define policy. All of these individual moving parts are in their own way as bad as the old mini directories as each represents a chance to foul things up ranging from downright poor implementation (e.g. where the entitlements table in the app database becomes a juicy target for attack) through to management cost holding down all of the complexity (just how do you persuade the auditors that person A in role X can sell a thingy, but only with person B in role Y’s approval?). The answer to these issues is of course…

Directories 2.0 (the future – for a while at least) – entitlements services do for fine grained authorisation what directories did for course grained authorisation. They centralise the stuff that makes sense, they allow delegation of the stuff that really shouldn’t be centralised, and they bring consistency and a coherence of approach. Entitlements services typically consist of three tiers:

• Policy Administration Point (PAP) – a place where administrators define roles, and the polices that map those roles to permissions against underlying resources. This can be done in a standards based way using a vocabulary like XACML. PAPs also support a bunch of reporting functionality to help keep those auditors at bay.
• Policy Enforcement Points (PEP) – the sharp end of the operation, where questions about whether a user can do something to a resource get asked and the answer gets acted out. These can be implemented directly into custom software using SDKs, and PEPs may also be available for commonly available infrastructure software like web portals, relational databases and instant messaging platforms.
• Policy Decision Points (PDP) – the middle tier between the PAP(s) and PEPs so that things scale nicely. Policy decision points are where questions about entitlement get answered (to make things go really fast the PEPs might cache these answers to save a service call each time a decision needs to be made).

So… what this should mean is that once enterprises have chosen a PAP from the vendor of their choice and rolled out a layer of PDPs all that they then need to do is start leaning on their software developers and suppliers to put in a suitable PEP rather than baking in their own mini PAP/PDP in the way that the dark ages stuff had its own mini directory. This is kind of where things run into trouble right now… it’s early days, and PAP/PDP infrastructure is hard to come by. Worst of all there isn’t yet the entitlements service equivalent of LDAP (let’s call it something like XSSIP for eXtensible Security Service Interface Protocol). XACML looks a lot like LDIF in this context, but I doubt that directories 1.0 would have worked out as it has if everybody needed to have multiple directories to support various products.

I therefore have a call to action – we need a open, industry standard interface to be defined between PEPs and PDPs. I realise that this won’t be easy, but it’s got to be easier than managing the baked in entitlements mess that confronts us today, which means that there’s a healthy market out there.