Getting the Last Word In on Metadirectories

I doubt it. I doubt that there will be a last word on metadirectories for a long time to come. Technology that works has a way of sticking around, even when they have outlived their purpose, and are forced into the substrate of a new and improved "solution". But I did want to respond to a couple of things that Matt Flynn brought up in his post "Metadirectories Aren't Dead (They're Just Aging)".

First, he outlined a use case that he (I think) postulates is best solved by Metadirectory. I won't recount the whole use case here (read his post to get it), but it involves three identity stores (HR, AD, and a DB) and synchronization between them of attributes that each one is authoritative for. My answer to his question "Is a virtual directory the best solution to meet these needs?" is "No, it isn't, but Virtual Directory + Provisioning is". Which is exactly what my post that he was replying to posited.

Now, I'm not trying to be glib here. Metadirectory can definitely solve this use case. But it will be a point solution. The "Aging" that Matt refers to comes into play when you consider that this use case will inevitably be added to with requirements for approval workflows, compliance and privacy controls and upgrade issues. Metadirectory (and Virtual Directory alone) would never be the right solution for those needs because (like Virtual Directory) it is simply an IT tool lacking the Business layer that Provisioning provides. So, the solution will require provisioning. In my experience, there is always a need to look forward to what is coming next before deciding on the solution, which is why in my (relatively medium-term) career, I have seen way too many customer requirements that try to bolt-on provisioning onto an existing metadirectory deployment because it was falling short. A number of times, the metadirectory was stripped down to a mere shell of itself as most of its functionality was moved into the provisioning solution.

I may be biased here (coming from a provisioning background), but nobody is simply looking for point solutions any more. And in any case, my hope is that eventually all of this will go away as we move to Service-Oriented Identity (as Burton calls the Identity Services concept).

Matt goes on to state:

There has been a ground swell of apps that directly support Active Directory as the user store. So, maybe the next versions of the HR and LOB apps in the above scenario would attach directly to AD eliminating the need for any solution here. As prevalent as AD has become, that seems more likely than mass-consumption of virtual directory technologies. And it's probably what Jackson was alluding to (Quest enables *nix systems to leverage AD).

Well, from the standpoint of a deployer/implementer, I can certainly understand the attraction of the above. But as a product architect and technologist, all I can say is "No, No, No". Why would we want to tie ourselves into a non-competitive, no-way-out scenario that we see repeated over and over in the OS and Mobile Provider worlds? Choice is necessary, nay vital, to innovation and growth. The minute you lock yourself into a single provider model, you are doomed to forever be curtailed by what that provider dictates. Virtual Directory provides a nice abstraction that frees you from having to make these very decisions on which directory to support (something LDAP was supposed to do, but didn't).

And how are more applications supporting AD anyway? A lot of that has to do with the emergence of Virtual Directory solutions. A number of applications in the Oracle stable today claim to support AD as the identity store. The mechanism for all these is moving to Virtual Directory NOT because Oracle has a Virtual Directory product, but because maintaining adapters/connectors/plugins and what have you for all LDAP variants is a colossal nightmare.

Metadirectory is aging, but the IdM industry is a lot like the ruthless fashion world, where age has no place except for a few niche areas.

Comments:

OK, how come Oracle isn't helping others develop LDAP enabled applications in a way that eliminates variants? Although Oracle isn't responsible for the mess out there, it is smart enough to teach folks how to do things better. Virtual Directory feels like it is an opportunity to do even more worst practices ...

Posted by James on July 07, 2008 at 02:17 PM EDT #

That is a a huge claim there. Is it possible that the "groundwell of apps that directory support Active Directory" is due to "emergence of Virtual Directory solutions"? How can you back that claim up? It's obvious to me that companies should have a virtual directory in their infrastructure, but how many actually do? And how many app dev teams are even paying attention to this space?

Posted by Ash on July 08, 2008 at 03:58 AM EDT #

Hi James, Actually we are. I'm sure you've looked at what we're doing with the Identity Governance Framework, including some new standardized APIs and donated code to the Liberty Alliance. Obviously we'll continue to build on this. The big problem will remain all of the existing code that's been written to take advantage of directories since about 1995. Active Directory wasn't even around until several years later and some of this code (portals, etc...) has remained until today. Plus it's actually pretty hard in Java or non-MS languages to take advantage of Kerb+LDAP together when talking to Microsoft Active Directory. Clayton

Posted by Clayton Donley on July 08, 2008 at 07:02 AM EDT #

I guess that when something else other then Windows becomes the predominant desktop solution that AD will be replaced by something else. AD is the directory in just about every organization running Windows. Let me see. What does that work out to be? 99% of them out there? Since they already are locked into AD why not use it? Oh I know, then they might not consider using the Oracle (virtual or meta or otherwise) solution.

Posted by Martin on July 12, 2008 at 06:30 AM EDT #

See http://jacksonshaw.blogspot.com/2008/07/james-unanswered-questions.html

Posted by James on July 15, 2008 at 11:02 PM EDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

bocadmin_ww

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