Single Directory Paradigm

16 May 2006

It does not work. More exactly: the deployment of single, unified directory system for identity management purposes in a medium-to-large sized enterprise environment is infeasible. At least in next few years.

I've seen to many failed attempts to implement single directory system. I can understand the motivations, though. I can see the clean architectural intention to "clean-up" the data stores and unite them in one place. That is usually a good thing to do inside a systems. But not necessarily accross different systems.

The most severe problem here is the incosistency of the data:

• Inconsistency of identifiers. One system expects user identifiers based on employee numbers ("nl123456"), other application expects surname-based IDs ("semancik") and yet another application has freeform identifiers ("rse"). In theory you can store all of the IDs in one directory record. The "uid" attribute is multivalue, no problem. But only few applications support that in practice.
• Inconsistency of access control. One application makes access control decisions based on LDAP groups. Other uses roles native for Sun Directory Server. And most applications does not really care and base access control decisions on their own proprietary attributes.
• Inconsistency in object structure. Different applications have different ideas how the object should look like. Each application is likely to define its own structural object class for the data. There may be only one structural object class per entry. Well, now we have to re-engineer the LDAP schema to use auxiliary objectclasses. While the should be no difference for the application, some applications will not run. The rest may run, but the vendors may claim that the warranty and/or support agreement was broken and that they will not provide support or will support that setup only in case they are "motivated" by astronomical support fee.

There are also other issues to consider:

• Directory server is not an authentication server. While the directory system can validate user password, it should not be considered an authentication service. The features of directory server are very limited in this area, usually limited to what SASL can provide. The correct approach would be to deploy an authentication server that will store data in the directory server. And use directory server only for the purpose it was designed: a database.
• Directory server is "statless". Well, it's weird to talk about a database being statless. But from the user authentication point of view the directory is stateless. It does not (and really should not) keep user sessions. It does not know it the user is still logged in. In fact, it does not even know if the user had logged in. Yes, it might know if the user had supplied correct password, but that may be only necessary, not a sufficient condition for authentication.
• Deprovisioing of stateful applications is a major problem. From the security point of view the deprovisioning (deleting of user accounts) is much more important than provisioning. And directory-only deployment cannot do deprovisioning of stateful services. For example user home directories, mailboxes, etc. If you route all your authentication through directory server, the user may not login anymore. But the state will remain. Will take place, harmful content (maybe accessible by other users) may be there. Or maybe even backdoor ...

The conslusion is simple: you need directory system, maybe even single directory system, but you will need other tools also. The user provisioning system is the tool that you will most probably need. And unless you have totally crystal-clear enterprise architecture, there is no way around it.

This was one of the points of my presentation at InfoSeCon conference. You may find the complete paper on my "papers" page.