More Complex Identity Integration

I have had some questions recently about what I mean by comments about "more complex integration".  I have had a few people ask me through my blog and recently at Catalyst in San Diego, and so perhaps I should clarify.  What IS my point of reference to "more" complex? 

Quoted from http://identityinfrastructure.blogspot.com/2008/02/oracle-virtual-directory-webinar.html:

Identity Data Delivery: Oracle Virtual Directory Webinar

... offer solutions to more complex integration problems that you can face that require more feature sets...

My point of reference was in relation to some virtual directory products which are basically LDAP proxy's.  It is not always apparent the issues you will face when planning an identity deployment.  So here are a few examples of what I would consider out of the scope of most LDAP proxy services.

1) integration between profiles where a common key is not present

when a common key is not present in all data sources, this requires correlation and complex matching rules to be used to disambiguate users across systems, for performance you need to do this off-line processing (this is something many virtual directories would try to do dynamically, in real-time for each query, if at all). 

2) Projects that could benefit from "push" not only "pull" technology.

Sometimes to achieve identity integration, you need to provide for only only "pull" (search/query) but also "push" (synchronization) technology (needed for things such as provisioning). Being able to leverage ESB technology for example has huge benefits to being adaptable to future needs. 

3) Deployments that require a different tree structure than what exists in current identity sources.

For some projects, the integration of the sources requires a tree structure that does not match any of the existing DIT's.  It is necessary to have the ability to design a new DIT based on existing information, but in a different structure. 

4) Deployments that require, or could benefit from information that lives in legacy applications, accessible only via web service, and/or one or more databases in which the data you need is located in multiple linked tables (complex relationships).

This requires a preservation of the context of the objects and the ability to build a modeled view of those objects based on the requirements of the initiative.  This is again out of the scope of an LDAP proxy service that is offered by most virtual directory vendors.

Also, think long-term.  Often we do not care enough about other feature sets because they don't see the need today.  Integration issues tend to get more complex, not less complex over time. Just because you are not facing these types of issues now doesn't mean that you won't the future. More times than not we avoid using certain identity information only because of the complexities in doing so.  There are certainly more options for identity integration than those of LDAP proxy capabilities offered by some virtual directories.