Tag Archives: IdM

Good summary of Sun’s open IdM projects

Luca Mayer has this summary of Sun’s open source IdM projects. I have some experience with OpenSPML (obviously), and I have fiddled with OpenDS. There is some great stuff there.

I hope this all survives the acquisition.


BMC and IdM

Felix Gaehtgens of Kuppinger Cole has some interesting observations about BMC’s new position on IdM (and gives me a nice mention as well).  Radovan Semančík has some interesting speculation as well. Both posts are well worth your time if you are interested in BSM or enterprise IdM.

And of course TalkBMC has lots of great bloggers talking about BSM and other topics.

IGF and LDAP, again

Phil Hunt has some good thoughts here on my recent post about IGF and LDAP. Just to be clear I am not suggesting that IGF replaces enterprise AD. But as I understand the some of the IGF proposals around the Identity Bus concept, IGF APIs would replace LDAP APIs on the client side. At least for new applications. From Phil’s post:

The nice thing about CARML is that it is just a declaration. There is nothing saying a CARML declaration cannot be created by hand for an existing application. Though we are working on an open source implementation, it does not have to be used for applications and infrastructure managers to receive benefits from IGF. The new API is really about creating appeal for developers. Developers want something very different than enterprises. They want to be able to write flexible applications without having to spend 90% of their time writing code to support varied deployment scenarios and varied protocols.

For business, the benefits of IGF are going to be mainly around risk management and privacy as demand to use personal information increases beyond current traditional enterprise directory content. Enterprises wanting to use identity-related information from HR systems or CRM systems already have to worry about legislative and regulatory issues. While manageable today, the processes are largely manual and forensic in nature. It’s a situation that cries out for standardization.

As I said, I wasn’t suggesting that IGF replaces AD. But if you expect developers to migrate to a new way for developing client applications you need to give them a compelling business case.

Let take a concrete example. Suppose an IT shop wants to build a replacement time card application. If the requirements are that the web app looks the current user up in AD and routes the time card to the person in the manager field for approval, we know what the problems are. There could be data integrity issues where the manager field is not getting properly updated. There can also be compliance issues.

So IGF can tell the app developer what the data quality is for the manager field. But what is the business value? They still need the information regardless of the data quality. Yes there is a compliance issue. But again, what is the business value? The manually process of noting the field access by the compliance person only needs to happen once.

Switching to a new identity API is going to require tools and training. That is going to come out of the project budget and schedule. What are you going to tell the project manager to convince him to commit budget and schedule?

We all agree that for enterprise identity data AD is the clear incumbent and that isn’t going to change anytime soon. But on the application side LDAP is also very likely the incumbent. And you are trying to change that.

All I was trying to get across (not well I fear), if that displacing an incumbent technology is very difficult. I personally hope it happens on the client API side. But my past experience working on identity service standards tell me it’s a big hill to climb.

I have failed to communicate

Clayton Donley of Oracle makes some excellent points here about my “Elephant in the Room” post.  But I have apparently done a poor job in communicating the whole point of the post. In his post:

What I think his post misses is the fact that most LDAP access in most applications is poorly written, even when using ADSI or ADO to talk natively to Active Directory. I can’t count the number of virtual directory deployments that we’ve sold to help customers in environments that were nearly 100% Microsoft (ADO/ADSI-enabled apps talking to Microsoft AD). Many of these deployments were to get around bad schema assumptions, others were to get around topology issues or forest boundary issues.

While we sell virtual directory technology, we hate making our customers pay money to solve such tactical issues. We want to be layering on higher-order value.

So when Phil Hunt or others talk about the Liberty IGF project, what they’re really saying is that we want a better way to give application developers a way to code something in a way they understand and can do well rather than a native access protocol that requires specialization. So while LDAP isn’t going away and everything from virtual directories to identity buses will need to support native access over LDAP to be successful, not looking at what developers are learning and using every day would be a mistake.

Keep in mind that developers must integrate with a LOT of technologies to build an enterprise application or portal. For example, a portal may be integrating with HR, CRM, and ERP systems. That integration is increasingly happening via web services. Giving these developers a mandate to use a completely different type of technology to integrate identity will only make identity more specialized and less standardized and understood over time. That is a recipe for disaster.

I did not mean to imply LDAP was a better choice that Liberty IGF. I was in fact the BMC rep to Liberty TEG and am very supportive of their work. I also agree there are a lot of problems with LDAP and how developers use it.

But having been involved at some level in the standardization efforts of DAML, XRPM, DSML v2, SPML, SAML, WSDM, OATH, Liberty, WS-Trust, WS-SecureConversation, and WS-Federation. I have spent a lot of time working on identity service standards and developing implementations of those standards at several different companies.

But the hardest thing is getting adoption of these standards. The point of my post was not to suggest that standards for identity services other than LDAP aren’t a good thing. The point was that to drive adoption you have to accept the reality that AD and other LDAPs have the predominant mind-share today.

To many enterprises, LDAP is their one identity hammer. And they see all their identity problems as nails. If we want them to put down the LDAP hammer and pick up the IGF pneumatic impact wrench, we have to explain to him in real world business cases why it’s better. Because they  know the LDAP hammer will work and they already have it in their tool box. The IGF pneumatic impact wrench is a strange new tool to him that they must first understand and second justify purchasing.

Of course AD isn’t all identity in an enterprise. But for extranet identities you will have to justify why IGF or some other identity service is better than just throwing in an ADAM, OID,  or OpenLDAP instance. Or even a virtual directory like OVD or OptimalIdM VIS (for the .NET centric customer). The enterprise architects know they already have a wide variety of tools and APIs to leverage LDAP. They don’t yet have those for IGF and other identity services.

Bottom line – identity services will not reach the level of adoption to where you could say there is an “Identity Bus” until there are compelling business cases made for it. Enterprises not only have to adopt the identity service standards, but they need to make vendor support of those standards a selection criterion to drive adoption.

Don’t Panic!

Don’t Panic” is the friendly advice from Douglas Adam’s Hitchhiker’s Guide to the Galaxy.


This is also the advice given by the Burton Group concerning HP’s recent “Identity Retrenchment”:

First and foremost, current HP customers should not panic. HP has no intention of abandoning its existing Identity Management customers.  Your first step should be to contact HP for clarification of the situation; HP is in the process of reaching out to all of its Identity Center customers, and you are undoubtedly already on their radar.  Existing customers will, however, need to decide going forward whether they will stick with their investments or consider moving to another product. Even if the decision is to move to another product, HP’s strategy and commitment allows customers to exit in an orderly and timely fashion.

Then comes the bad news for HP customers:

After not panicking, existing customers must think strategically. It’s fair to assume that HP will not be able to keep pace on product enhancements when compared to other vendors who are fully committed to the IdM market and who are deriving revenue from new product sales. Organizations with HP Identity Center deployments will need to evaluate all of their options going forward.

Interesting times.

An Optimal Solution for Virtual Directories

Today at DEC2008 Optimal IdM unveiled their new Virtual Directory product. The Virtual Identity Server (VIS) is unique in that it is a pure .NET virtual directory intended for use with AD in a heterogeneous environment.


I expect this product to do quite well because it hits a real sweet spot in the market. A simple to install Virtual Directory based on Microsoft technology for the AD centric enterprise. I know from experience that there are a lot of enterprise customers that just don’t want Java solutions for their Windows server. For these enterprises VIS should serve as a nice compliment to AD and ILM.


Also the founders of Optimal IdM came from OpenNetwork Technologies prior to it’s acquisition by BMC Software. These guys know IdM well and they know what customers are looking for.


If you are looking for a Virtual Directory solution for AD, I would give this product a try.


[Full Disclosure – I worked with the founders of Optimal IdM at OpenNetwork Technologies]