Last week I've been talking with Andrew Ferguson and Steven Legg of eB2Bcom. Probably you've never heard of them, at least as long as you are neither from the APAC region nor working in the government and defense business where they have most of their customers outside the APAC region. eB2Bcom is, first of all, a system integrator and distributor of IAM and GRC products.
But eB2Bcom is as well the company which develops the View500 directory service. You haven't heard of this product? At least it is worth to have a look at. Basically, it is a directory service which goes beyond typical directory service offerings, which mainly focus on being the best LDAP server. They have for example integrated XML support, for SAML, XACML, or ebXML. Thus, they go well beyond the DSML support some directory services are offering - with DSML being in fact sort of a web service incarnation of LDAP. The difference is that the semantics of XML documents are supported. Other features include the matching of synonyms or typing correction for improved search and indexing.
eB2Bcom ist adding additional features. The support for SAML and XACML is particularly interesting. In adding these capabilities to the directory service, that system can for example act as an integrated identity provider for federation. Instead of having a federation system and a directory server, it is one system with obviously less communication overhead. The same is true with XACML support and the directory acting as PEP (Policy Enforcement Point). One system instead of two or three in typical implementations.
Interestingly, what Microsoft is doing around Active Directory with ADFS (Active Directory Federation Services) or the server components of "Geneva" isn't that different. It is sort of "pimp my directory server" by directly adding additional features instead of delivering separate products. The closer to the directory these features are implemented, the more efficient they are. On the other hand, we might end with well integrated solutions which lack important features. Thus this approach isn't a no-brainer, for sure. But I think it is really worth to consider if there aren't features which are best integrated with directory services because the directory service is, anyhow, asked all the time. Thus, instead of having the directory service providing just a part of the answer and another system adding to that answer (with repeated requests to the directory server, complex caching,...) it might be a good idea to do all these things in one place.
That won't solve everything - but it is an interesting option. By the way it might as well be a good choice to add some virtual directory service capabilities to a directory server like Sun has done this with their Sun Directory Server instead of fully relying on an external virtual directory service. Might also provide a better performance especially in the situations in which most of the requested data is in that directory.
Another interesting point is that XML-enabled directory service will become an interesting option for a centralized policy management. They can store these policies and provide them or answer requests about these policies. Another emerging field where that approach might become popular over the next few years.
I will have a look at the evolution in the directory services market. And, from a vendor perspective, it is worth considering these options because it would move directory services back from a commodity to a market segment where companies can earn a lot of money because they have strong unique selling proposition due to the services they've added to their directory service.