You Don't Need Universal Directory To Solve Federated Provisioning Problems - You Just Need Identity Virtualization
By Mark Wilcox - CTO - Oracle Consulting Security-Oracle on Mar 04, 2009
Dave Kearns most recent article mentions a "universal directory" to help solve the federated identity provisioning problem. And as Jackson Shaw points out - we tried this with X.500 and it didn't work out.
But I would argue that Dave is on the right path but wrong implementation.
If you take a broad look at federation - it's really just the traditional enterprise SSO problem except across organizational boundaries. I know for SAML crowd they will be saying "duh" but for the other 99.99999% of the human population (I say human because according to my dog, 100% of the dogs know this but only 33% of cats) - this is not well known. All of the other bits involved with federation (like attribute exchange) are really attempts at trying to solve the provisioning problem - but obviously haven't had much success yet.
Now if the applications at the service provider side are able to keep their identity lookups to a service layer (whether that is LDAP, Web-Service (SOAP or REST) and longer-term IGF) then you really can avoid provisioning.
Instead at the SP side - applications would lookup the identity information to an identity virtualization layer (like Oracle Virtual Directory) which would abstract where the identity lives. For local accounts - it would pull the data from whatever local repository. However, for the accounts that are coming from the IDP - it could retrieve them from the IDP. This could be the IDP's LDAP server (via a directory firewall like OVD) or database (also via OVD at the IDP).
This wouldn't require any mythical "universal directory" - a point-to-point integration works quite well. Which reduces the need to provision at the SP without the problems of a X.500 type solution.
And you could do all of this today - using existing OVD product.
In longer term IGF (via the ArisID Beans API) would make it easier on developers because they could just define the interactions (e.g. getCustomerShippingAddress) and objects (e.g. a PersonAddressObject) without really having to worry about things like protocol or where the data is coming from (a key tenet of object-oriented development, SOA and the Web itself that has never really meshed within developer's mindset in regards to identity). And because the virtualization will most likely happen closer to the application (e.g. within the app server itself), it will further simplify the configuration & governance of the identity data.