Directories 2.0 – entitlements services

25Mar08

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.

Craig – you’re quite right that the req-resp mechanism provides the necessary semantics for allowing PEPs to talk to PDPs, and if both support XACML (a fair assumption for the time being) then we have a common vocabulary in which to ask questions and get answers. I still feel however that there’s something missing at the plumbing level that prevents me from grabbing vendor A’s PEP and hooking it up to vendor B’s PDP. Although they both share a common vocabulary they don’t know how to call each other. This could of course be dealt with by plucking a few items of the WS-* smorgasbord, with Addressing and MEX looking likely suspects. I feel however that this route quickly descends into SOA hell – it shouldn’t matter that each vendor has their own WSDL for their PDP service interface because PEPs can just look it up in the service registry and dynamically bind. Clicking my heels together and returning from SOA hell to the surface world; we find that service registries don’t exist, all the popular services have simple RESTian interfaces, and very late binding is acknowledged as impossible to pull off. This leaves us facing the challenge of defining something that has a simple and lightweight set of core functionality (e.g. to act as a transport for XACML req-resp) that is easy to find.

We’ve been working in this space for quite some time now on our open source ESOE project. The way we’ve essentially hooked up the communication is to have the PEP implementation part of a SAML 2.0 SP implementation which in turn can consume SAML 2.0 metadata and resolve exposed endpoints of the trusted PDP, certainly not *the* solution but its working for now.

With the PEP and PDP interaction working quite nicely we’re now moving onto developing a much nicer central PAP interface and starting to think about how we might be able to allow policy changes to occur from remote systems securely. Naturally it would be nicer if administrators don’t have to leave their application of choice and goto some central PAP to update access control policies.

We release everything under Apache 2 licensing so if anyone wants to take a look or help us solve some of these problems then you’re more then welcome to come on over to http://esoeproject.org

You’ve got a good point about bootstrapping the communication process.

What we’ve done for the OASIS interop events (I represented IBM at the Burton Catalyst Interop in 2007) is make it as simple as possible – send a SAML-wrapped XACML Request in a SOAP envelope to a given URL.

This appears to be the approach taken by vendors prior to the events, so I don’t think there’s a big an issue as first appears.

Perhaps a valid task for the XACML TC could be to define a standard WSDL for a PDP service? While we don’t technically need a WSDL, it may help to allay concerns such as the ones you have.

What do you think?

A REST binding would be great too, but in all honesty I don’t know enough about the technology to give a meaningful comment. I’m a SOAP + WS-* man. :P

Of course, by “simple as possible” I mean “as simple as possible by building on other specifications”. A REST interface could (would?) be simpler in absolute terms, but using SAML to transport the XACML requests means we can leverage the defined SAML transport mechanisms.

Bradley – thanks for the pointer to ESOE, this looks really cool. It’s not quite what I was asking for as it’s moving complexity into the PEP rather than creating uniformity at the PDP, but I like the overall architecture. Any thoughts/plans about information card integration?

Craig – I think a standard WSDL for the PDP service would be exactly what’s needed. How do we get this onto the XACML TC agenda?

BTW WSDL doesn’t have to define a SOAP interface, it can be equally used for REST (though obviously the bindings aren’t defined in the W3C standard). But… it seems that the solution space under discussion is converging on reusing a lot of stuff that’s been done already with SAML, so I guess the angle brackets probably win out on this one.