The elephant in the room

In the latest installment of the Great Meta-Virtual-Directory-Identity-2.0-Bus-Hub Debate, Dave Kearns is groping elephants. Dave allows that we are all really talking about the same Meta-Virtual-Directory-Identity-2.0-Bus-Hub, but like the three blind men and the elephant, we just can’t agree we are all groping the same animal.

Kim Cameron elaborates what features needed for the Meta-Virtual-Directory-Identity-2.0-Bus-Hub. Kim’s requirements:

  • By “next generation application” I mean applications based on web service protocols.  Our directories need to integrate completely into the web services fabric, and application developers must to be able to interact with them without knowing LDAP. 
  • Developers and users need places they can go to query for “core attributes”.  They must be able to use those attributes to “locate” object metadata.  Having done so, applications need to be able to understand what the known information content of the object is, and how they can reach it.
  • Applications need to be able to register the information fields they can serve up. 

Today’s virtual directories just don’t do this any better or any worse than metadirectories do.  Virtual directories expose some of the fabric, just as today’s metadirectories do, but they don’t get at the big prize.  It’s what I have called the unified field of information.  Back in the 90’s more than one analyst friend made fun of me for thinking this was possible.  But today it is not only possible, it is necessary.

Phil Hunt throws in his requirements Meta-Virtual-Directory-Identity-2.0-Bus-Hub:

  • There should be a new generation of APIs that de-couple developers from dependence on particular vendor implementations, protocols, and potentially even data schemas when it comes to accessing identity information. Applications should be able to define their requirements for data and simply let the infrastructure deal with how to deliver it.
  • Instead of thinking of core attributes as those attributes that are used in common (e.g. such as surname is likely the same everywhere). I would like to propose we alter the definition slightly in terms of “authoritativeness”. Application developers should think about what data is core to their application. What data is the application authoritative for? If an application isn’t authoritative over an attribute, it probably shouldn’t be storing or managing that attribute. Instead, this “non-core” attribute should be obtained from the “identity network” (or metaverse as Kim calls it). An application’s “core” data should only be the data for which the application is authoritative. In that sense, I guess I may be saying the opposite of Kim. But the idea is the same, an application should have a sense of what is core and not core.
  • Applications need to register the identity data they consume, use, and update. Additionally, applications need to register the transactions they intend to perform with that data. This enables identity services to be built around an application that can be performant to the application’s requirements.

Since Dave first brought up elephants, let me point out the elephant in the room no one is talking about; AD. For the vast majority of enterprises AD plus other identity services already serves the role of the identity hub. It is your company’s identity store, authentication service, authorization service, and attribute service. It is used to identity enable your remote access gateways and your email servers. If you are using a Virtual Directory, chances are AD is at least one of the stores behind it. Other companies such as Quest and Centrify have developed products to extend AD authentication to wide range of heterogeneous OSs.

Vendors have created products for provisioning from AD out to disparate systems. When I started at Access360 AD didn’t exist yet and our strategy was to get the buy-in from HR up front because the HR system was the source of all identity information. By the time I started doing provisioning at OpenNetwork Technologies, we assumed that customer already had an HR feed into AD.

While I like both Kim and Phil’s vision of what a Meta-Virtual-Directory-Identity-2.0-Bus-Hub should be, the big question customers are going to ask is why? Companies have spent an incredible amount of money building out AD as their identity hub. What specific cost saving or new capabilities will they achieve by implementing this vision?

Kim thinks web services are the answer. But what specific web services and what specific advantages do they offer? Will they be easier to adopt than LDAP? If we think LDAP hard for developers, wait till we try explaining WS-CombinatorialExpansion. 

Phil thinks a key requirement is to abstract the protocols and schemas. Is that really an important requirement given the near ubiquity of AD?

I know this isn’t pleasant to hear, but AD is the incumbent. It’s nearly everywhere. It’s scalable to millions of users. The LDAP protocol is efficient and mature. It’s supported by countless applications. Before a customer considers displacing or adding another identity layer on top of AD they are going to need real cost savings or additional capabilities and order of magnitude over what they have now.

That’s not to say LDAP is the perfect solution or even the best solution. But if we are going to propose a better one we have to say specifically why it’s better. With real examples that customers can relate to. With cost savings and capabilities they can’t reach today with AD.

Advertisements

4 responses to “The elephant in the room

  1. I think you may be confusing identity from an enterprise directory or NOS perspective with the broader identity perspective of how applications share and use personal information (e.g. information an employer shares with an outsourced service provider for benefits or corporate travel). Should sharing of personal information happen? Why? When? How? What about privacy?

    If it was just about SSO, then you are correct, none of this would be needed.

  2. I was speaking more broadly that simple a NOS perspective. I was speaking about the general identity ecosystem that you have in an enterprise that includes NOS but also includes other services such as time cards, education, CRM, etc. There is a small subset of information that normally would be shared by external service providers such as 401K, Travel, and other benefits that would not be in AD. But from my experience this does not represent enterprise identity, but rather an application that depends on enterprise identity. For instance it would be reasonable for an enterprise to use AD as a basis for provisioning (and more importantly deprovisioning) and employee to the travel SP even if some of the information that is needed must be retrieved from another location.

  3. Pingback: Clayton Donley's Blog

  4. Pingback: I have failed to communicate « Identity Blogger

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s