If pretty much every Fortune 500 enterprise has Active Directory, why should any of them consider yet another product?

Martin (no last name) left a comment on my post that included the following point:

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?

Here is my point. Martin says “AD is the directory…”. I say that “AD is a directory…”, and that too because Windows forced it on those enterprises, not because of their Identity Management needs. Yes, almost all the Fortune 500 have AD, but are they using it as an Identity Store, or as a Windows Account Store (which is very different)?

Obviously our opinions are shaped by our experiences. My experiences, coming from the provisioning world, would be different from James or Jackson’s. In a lot of the projects we were involved in, AD was a downstream repository, a target of the provisioning system and not the source of identity data. That was usually an HR system or, more often, a Sun directory. Most of the time, the provisioning system would push the bare minimum attributes to AD to enable the Windows environment to work.

In a few deployments, we actually were responsible for populating a directory with identity data so it could act as an identity store for other applications. Most of the time, that directory was a Sun directory. So while AD may be more widely deployed, I would contend that based on my small but relevant sample size, Sun is dominant in the Identity Store business. And that is really what we are talking about here – what should applications be going to for their identity data. Sure, AD being more widely deployed positions it to be used as an identity store, but that is seldom the case, primarily because AD administrators often closely guard their environments and do not want it overloaded with data or consuming applications.

Again, when James asks about practical futures, my hope is that the future eliminates all such arguments about directories and metadirectories by having applications code against Identity Services APIs, like the IGF APIs or the Higgins IdAS APIs. James asked what we at Oracle are doing to help application developers. Clayton mentioned our work on the IGF, and the APIs that are being defined as part of it that eliminate the need for application developers to have to worry about LDAP, instead providing simple APIs that use a provider model to get the data from where it needs to. And I have joined the Burton Groups Identity Services Working Group (now that it is open to vendors), where I hope to work with the community to help advance the concepts and reality of Identity Services. Hopefully, soon, this will be a question that nobody will need to ask any more.

By the way, why is it that architectural purists don’t ask when Microsoft will make it possible for Windows environments to work against any directory and not just AD, but Oracle Applications must support directories other than OID? In the end, both Microsoft and Oracle are wrong to push proprietary stores into deployments, contributing to the mess we have.

Tags: Active Directory, Identity Hub, Identity Services

I did not in any way mean to imply that the majority of applications that are coming out with support for AD do so using a Virtual Directory. What I was actually trying to say (poorly in the end) was this: “And how are more applications looking to support AD anyway? A lot of that has to do with the emergence of Virtual Directory solutions”. Let me talk about this separately in the context of Custom and COTS applications.

There are a large number of custom enterprise applications that support LDAP that were tied to a particular directory, usually something non-AD (most application developers would develop against free LDAP systems like Sun). This was a reality that proved to be a boon for provisioning vendors (like us), but a curse for provisioning implementers, as we then played the role of populating these non-AD directories from the main AD infrastructure. A lot of those same applications are now looking to support AD in addition to (or in place of) what they already supported OOTB, and from what I see, they are doing so by shifting to a Virtual Directory based approach. This shift seems to be specific to custom in-house applications (where Virtual Directory lock-in, a great point raised by Jeff Bohren, is not considered as big of an issue) and is prevalent in heterogeneous directory environments, where AD may be dominant, but is not the only directory available. Virtual Directory provides a nice abstraction to avoid having to deal with the heterogeneity of the environment, and allows consolidation of the spread out data into a single view. This is not really a concern in pure AD shops, but there are few large enterprises that are purely AD.

As for COTS application vendors, I mentioned what Oracle is doing with regards to their strategy on how to support multiple directories. And from talking to a few other application vendors, they are also tired of having to maintain connectors for every single major directory out there. This is one of the main reasons why there is an on-going effort to see if Oracle Virtual Directory can be made an embedded component (as opposed to its own server), something that is part of the middleware stack, so that it can act as a “directory connector” service in the application environment, freeing up applications from having to code against the idiosyncrasies of the individual directories. It is also a reason why so much emphasis is being put on some of the standardization efforts in Higgins and IGF.

Now, this is not to say that a lot of applications are not being built to go directly against AD, with little regard for other directories. All I meant was that from my vantage point (and it may be a skewed one because we are Oracle, so I am more than happy to have people contradict me or correct me on this), a lot of people are looking to support AD without getting locked into AD, and that is driving demand for both OVD and other alternatives.

James asked some good questions with regards to what Oracle is looking to do to help resolve this issue. I’ll get to those in my next post.

Update: Clayton has chimed in with some articulate and well-thought through responses, complete with examples, to this whole discussion. I should have just waited for him to come back and take this up instead of sticking my little neck out there

Tags: Active Directory, Virtual Directory

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.

Tags: Active Directory, Identity Services, Metadirectory, Provisioning, Virtual Directory

A global customer is implementing a “single forest, single domain” directory (MS AD), supporting among other things SAP and Windows – about 30,000 users. They have asked us to summarise the business case for additional IdM solutions given the single directory approach.

Dr. K says:
With all the material available today on identity management, it continues to amaze me how many people still ask their variations on the question “I have AD deployed, why do I need IdM?”.

The case for IdM is that of a business solution, not a technology solution. It is the business and security benefits it brings to the table – workflow, audit, attestation, separation of duties, provisioning policies – that drive its deployment in the enterprise. These are above and beyond any technical benefits that you get by introducing automated provisioning and password synchronization.

It should not matter if the enterprise environment is relatively simple from a technology deployment perspective. The business, security and regulatory challenges overlaid on that simple environment may still be complex enough to justify an IdM investment. As the cost of deploying IdM drops over the next few years, we will see a larger adoption of IdM in the SMB market. In fact, at OpenWorld recently, we had some customers talk about their experience successfully deploying Oracle Identity Manager within their  environments in the span of 4-5 months (from buy decision to production). Again, these deployments do not compare to our much touted deployments at Lehman Brothers and other large enterprises. Yet the business benefits they are deriving from their investment are just as important to them (if not more).

Being able to rationalize your environment enough to standardize on a single identity store is extremely important in making sure that your identity challenges are manageable. But that is a one time challenge that, though painful to go through, only gets you started on the path to identity health. IdM brings in the ongoing lifecycle management that is needed to make sure that it stays manageable, compliant, and able to continue to stay in a single identity store.

Tags: Active Directory