What About IGF and Existing LDAP Systems?

Jeff Bohren responds in his latest blog post to a post from Clayton Donley. The gist of Jeff's post is the suggestion that IGF replaces or changes AD. That is not the case.

But the hardest thing is getting adoption of these standards. The point of my post was not to suggest that standards for identity services other than LDAP aren’t a good thing. The point was that to drive adoption you have to accept the reality that AD and other LDAPs have the predominant mind-share today.

To many enterprises, LDAP is their one identity hammer. And they see all their identity problems as nails. If we want them to put down the LDAP hammer and pick up the IGF pneumatic impact wrench, we have to explain to him in real world business cases why it’s better. Because they know the LDAP hammer will work and they already have it in their tool box. The IGF pneumatic impact wrench is a strange new tool to him that they must first understand and second justify purchasing.

To be clear. Enterprise LDAP is a key part of what we are thinking about for IGF. The plan for IGF (and its components CARML and AAPML) is to develop a profile against multiple protocols (LDAP, ID-WSF, WS-*) used for identity information. Each profile will explain how IGF is used in the context of a particular protocol. For LDAP, the big challenge is what to do about existing applications. After-all, these applications aren't going to change for a long time - and probably do not need to. IGF is not a replacement for these protocols but is instead a layer that runs on top of them.


The nice thing about CARML is that it is just a declaration. There is nothing saying a CARML declaration cannot be created by hand for an existing application. Though we are working on an open source implementation, it does not have to be used for applications and infrastructure managers to receive benefits from IGF. The new API is really about creating appeal for developers. Developers want something very different than enterprises. They want to be able to write flexible applications without having to spend 90% of their time writing code to support varied deployment scenarios and varied protocols.

For business, the benefits of IGF are going to be mainly around risk management and privacy as demand to use personal information increases beyond current traditional enterprise directory content. Enterprises wanting to use identity-related information from HR systems or CRM systems already have to worry about legislative and regulatory issues. While manageable today, the processes are largely manual and forensic in nature. It's a situation that cries out for standardization.

Finally we should be careful not to focus exclusively on classic enterprise identity and ignore other business systems that use identity-related information. Many businesses have customer relationship systems that hold and retain customer information have most often not been ActiveDirectory or LDAP based. This is why IGF can't exclusively focus on LDAP or any other single-protocol and why it must function at a higher level.