Clayton Donley's Blog

Dave Kearns has followed up on Kim Cameron's posting from Friday.

1. Kim says that sometimes you need to copy data in order to join it with other data
2. Dave says the same thing, except indicates that you wouldn't copy the data but just use "certain virtual directory functionality"

Actually, in #2, that functionality would likely be persistent cache, which if you look under the covers is exactly the same as a meta-directory in that it will copy data locally. In fact, the data may even be stored (again!) in a relational database (SQLServer in the Radiant Logic example he provides).

Let's use laser focus and only look at Kim's example of joining purchase orders with user identity.

Let's face it. Most applications aren't designed to go to one database when you're dealing solely with transactional data and another database when you're dealing with a combination of transactional data and identities.

If we model this through the virtual directory and indicate that every time an application joins purchase orders and identities that it does so (even via SQL instead of LDAP) through the virtual directory, you've now said the following:

1. You're okay with re-modelling all of these data relationships in a virtual directory -- even those representing purchase order information.
2. You're okay with moving a lot of identity AND transactional information into a virtual directory's local database.
3. You're okay with making this environment scalable and available for those applications.

Unfortunately, this doesn't really hold up. There are a lot more issues, but even after just these first three (or even the first one) you begin to realize that while virtual directory makes sense for identity, it may not make sense as the ONLY way to get identity. I think the same thing goes for an identity hub that ONLY thinks in terms of virtualization.

The real solution here is a combination of virtualization with more standardized publish/subscribe for delivery of changes. This gets us away from this ad-hoc change discovery that makes meta-directories miserable, while ensuring that the data gets where it needs to go for transactions within an application.

Technorati Tags: identity bus, LDAP, meta-directory, virtual directory

While I may not agree that doing SQL through your virtual directory to get access to combined views of transactions and identity information is the right way to go (and I think Dave really wasn't trying to say that anyway), but...

I absolutely DO agree with Dave (and Vikas Mahajan) that there's no reason we should be building additional infrastructure around moving identity around vs. moving any other data around.

Let's keep in mind that a bus can move any arbitrary object from A to B or even A to B, C, and D.

The trick is to make sure that all of these points understand the object being passed between those points.

Just as multiple LDAP-enabled applications need to understand the same schema, multiple parties publishing/subscribing to a queue will need to understand the same messages.

This is true even though each application may only need a slice of that identity data. The overall structure of what is being shared. The Identity Governance Framework (IGF) actually gives you a standard way of defining the attributes present in a message you could accept/publish. It even provides a place for defining which attributes might be used as keys by your particular application, which helps in the previous discussion re: joins.

If we agreed to use IGF's CARML representation to define the attributes that would be present/required by an application and agree on what representation will be used to encapsulate those attributes, all you need is a standard message bus.

Of course, the question then becomes, who will take the messages off the bus and send updates to legacy applications and who will take updates from legacy applications and push them onto the bus in the first place.

This is where identity services come into play. Like virtual directory, they're simply moving data from one context to another so that everyone else doesn't need to adapt to the legacy environment and legacy environments don't have to adapt to each other.

Maybe I could ask my friend and colleague, Phil Hunt, to spare some time to post a quick example of how this looks in real life.

Technorati Tags: identity bus, identity management, LDAP, virtual directory