LDAP (Lightweight Directory Access Protocol) is well established. It is the foundation for today’s Directory Services, which support LDAP as a protocol and which usually build their data structure on the associated LDAP schema. There are many interfaces for developers to use LDAP, from the LDAP C API to high-level interfaces for many programming environments.
Even while LDAP is well established, it is somewhat limited. There are several restrictions – two important ones are:
- The structure of LDAP is (more or less) hierarchical. There is one basic structure for containers – and linking leaf objects (think about the association of users and groups) is somewhat limited. That structure is a heritage of X.500, from which LDAP is derived – with LDAP originally being the lightweight version of the DAP (Directory Access Protocol) protocol. X.500 was constructed by telcos for telcos, e.g. with respect to their specific needs of structuring information. However anyone who ever has thought about structuring Novell’s eDirectory or Microsoft’s Active Directory knows that there is frequently more than one hierarchy, for example the location and the organizational structure. The strict hierarchy of LDAP is an inhibitor for several use cases.
- LDAP is still focused on the specific, single directory. It doesn’t address the need of storing parts of the information in fundamentally different stores. But the same piece of information might be found locally on a notebook, in a network directory like Active Directory, in a corporate directory and so on. How to deal with that? How to use the same information across multiple systems, exchange it, associate usage policies, and so on? That is out-of-scope for LDAP.
I could extend the list – but it is not about the limitations of LDAP. LDAP has done a great job for years but there is obviously the need to do the next big step. An interesting foundation for that next big step comes from Kim Cameron, Chief Identity Architect at Microsoft. He has developed a schema which he calls system.identity. There hasn’t been much noise around before. There is a stream from last years Microsoft PDC, there is little information at the MSDN plus a blog post, there is the Keynote from this year’s European Identity Conference. But it is worth to have a look at that. The approach of system.identity is to define a flexible schema for identity-related information which can cover everything – from local devices to enterprise- and internet-style directories, from internal users to customers and device identities, including all the policies. It is, from my perspective, a very good start for the evolution (compatibility to LDAP is covered) well beyond LDAP and today’s directories.
I’ve put the concept under a stress test in a customer workshop these days. The customer is thinking about a corporate directory. Most people there are not directory guys, but enterprise IT architects. And they definitely liked the path system.identity is showing. It covers their needs much better than the LDAP schema. That proved to me that system.identity is not only for the geeks like me but obviously for the real world. Thus: Have a look at it and start thinking beyond LDAP. The concept of system.identity, despite being early stage, is a very good place to start.
[...] This post was mentioned on Twitter by Kuppinger Cole, Laura E. Hunter. Laura E. Hunter said: RT @kuppingercole: Beyond LDAP – have a look at system.identity http://is.gd/cWfic [...]
Funny, but totally off base.
LDAP allows more than one hierarchy. You can even have more than one schema used in a Ldap Server. My be M$ not implementing the RFC correctly is a reason not to support that, but it has nothing to do with LDAP being broken
LDAP allows you to refer data in many places through aliases. No need to invent another mechanism.
LDAP is not perfect, but you missed to point out the real problem in your article.
It is not about having multiple directories with different schemas and different hierarchies on one server. That is not the point, obviously. The point is that within one directory I have one schema. Within this schema, I have one hierarchy (which again is obvious when looking at the concepts of LDAP, the DNs, and so on). Thus based on the same set of data I end up with some inflexibility. I can for sure use Virtual Directory Services on top to create different hierarchical views but that is just a workaround.
Thus it is not about whether an RFC is implemented correctly (I assume that M$ is a biased abbreviation for Microsoft). It is also not about LDAP being broken, but LDAP being limited. By the way: For sure I know not only Microsoft Active Directory but many other directory services.
Aliases are not sufficient. That is again very obvious to any practicioner, because it is an inefficient workaround. Thus there is the obvious need to rethink this issue.
I’m pretty sure that I’ve got some of the points (which were examples). And just because the new concept has been developed by someone from Microsoft it is not necessarily bad. The real bad thing, from my perspective, is being narrowminded.
Emmanuel, just for the record, I've worked with X.500 and LDAP since the very beginning, and my company, ZOOMIT, did the first commercial implementation of LDAP. So there is no need to be derisive – I do actually understand how it works. The essence is that it implements the X.500 model. This model is based on named entities that represent real-world objects. The distinguished name (DN) is the base identifier of the objects, and consists of attributes strung together in a sequence out of which a hierarchy is constructed. Thus the identifier and hierarchy are conflated with the semantic contents of the object.
X.500 also has the concept of aliases. The alias is an obect that points at another object. It has its own name as a sequence of distinguished attributes. So the aliases are a second set of objects that live within a second hierarchy and point at objects living within a first hierarchy.
The main problem is that neither of these hierarchies have much to do with what programmers need. Let's face it. Hierarchical databases went out around 1980. People who build the vast majority of the world's applications don't use hierarchical databases – they use relational databases. They build hierarchies out of relationships, and don't hard-code them. This has a great many advantages, and these advantages explain why, in most aspects of development, relational databases have won out. Further, hard-coding causes a great many difficulties which we could drill into when we have more time. Now those of us who work in identity need to bring directory into alignment with relational databases so the world's programmers understand it and can benefit from the advantages it brings.
I can't discuss all the issues here, but will do so more in upcoming days on my blog, and I do invite you to continue this discussion with me there.
[...] la gestion des identités ? C’est en tout cas une piste explorée par Martin Kuppinger dans un récent billet. Deux reproches principaux sont faits à LDAP dans le domaine de la gestion des identités : [...]