Is Connecting to Multiple Directories Really Easy?

Back from vacation and finding a whole army of people writing about virtual directory while I'm gone.

Working backwards, I saw the following quote from Jeff Bohren in his entry about vendor independence in response to a few posts from our own Nishant Kaushik:

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.

Some examples:


  • 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.

Comments:

Post a Comment:
Comments are closed for this entry.
About

This is Clayton Donley's official blog. Views expressed are not necessarily those of Oracle.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today