Category Archives: Web Services

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.

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.

There was an interesting article on DSML recently (I ran across it in Dave Kearn’s IdM Journal). This is a useful summary, but unfortunately the article mixed in references to DSML v1 and DSML v2 in a way that will likely be confusing.

Just to clear this up, DSML v1 was a private vendor spec originally initiated by Bowstreet.com. DSML v2 is an OASIS Standard. There are some key differences DSML v1 only supported representing LDAP data and schema in XML but did not address web services. DSML v2 addressed web services. The two specifications are not compatible. The free DSML tools mentioned in the article are actually DSML v1 tools.

DSML v2 is supported by some of the main LDAP Vendors. DSML interfaces to LDAP servers include the Microsoft DSML Services for Windows (DSFW), the Netscape DSML Gateway, and the Novell DSML Support. Microsoft has also added DSML support to its .NET 2.0 Directory Services, although I haven’t had a chance to play around with it.

I had some peripheral involvement in the DSML v2 effort. While at Access360 I designed the new protocol for the enRole IdM server to communicate with the enRole provisioning agents. I create an XML/HTTPS protocol that was called the Directory Access Markup Language (DAML). DAML was basically a web services layer on top of DSML v1. It was actually pretty cutting edge at the time; the enRole system was using an XML/HTTPS protocol for provisioning while SOAP was still in development as standard. Access360 was of course acquired by IBM and the enRole system became the Tivoli Identity Manager (TIM). I don’t know if the DAML protocol is still being used, but you are likely to still see references to it in TIM documentation.

When the DSML v2 effort started with OASIS, the Access360 DAML spec was contributed as input to DSML v2, along with the Dir-XML spec from Novell. I had some initial involvement with the DSML v2 effort, but that ended when I left Access360 and joined OpenNetwork Technologies.

But I have always been a fan of DSML, which is why (for better or worse) SPML 1.0 was based on DSML v2.