Is Connecting to Multiple Directories Really Easy?
By Clayton on Jul 08, 2008
Back from vacation and finding a whole army of people writing about virtual directory while I'm gone.
BTW, having written code that supports multiple LDAP vendors at four different companies and three different programming languages, it’s really not all that difficult. The real power in virtual-directories is the ability to consolidate data from disparate sources, not abstracting the vendor for a single directory.
Having written similar code, I'll agree that some of the basic differences are pretty easy to navigate (differences between attribute names, for example). However, others are much, much more difficult.
- Active Directory returns groups larger than 1000 members in ranges. Other directories don't. This requires significantly different logic.
- Authenticating to Active Directory without Kerberos doesn't (or didn't) trigger actual logins, meaning that doing simple binds wouldn't respect bad password counts, etc...
- Account lock, account controls, password policies, etc... are completely different between directories
- Setting passwords is very different between AD and other directories
Now add in issues with using basic LDAP to navigate multi-forest AD environments, mixed-vendor LDAP environments, access to databases and web services, etc... and the requirement that applications would need to hit each of these...
Now you have a picture of why virtual directories are so widely deployed (and they are, though I can't share our numbers here at Oracle).
It's one thing to navigate this complexity in one application with a person like Jeff that has strong LDAP knowledge, but a completely different thing to expect that all of your off-the-shelf and in-house applications will have all of this knowledge and execute every step properly across all of these different kinds of systems.
Virtual directories remove that complexity by putting it at a service level. Change directories? Change a setting. Change applications? Change a setting. Add a web service with real-time data from an external source (perhaps a social network or real-time HR)? Change a setting.
Contrast that with the extra code, application rewrites, infrastructure changes, etc... that need to happen without a virtual directory and you see why Virtual Directory is the right way to go in almost every case.
And we wouldn't be pushing standards, such as the Identity Governance Framework and CARML, which will improve Virtual Directory interoperability, if we weren't fully committed to our customers' desire for standards and minimal vendor lock-in.