Posted 8:12 AM (1) comments

A herring of a different color

You almost had me, Kim. I read your latest entry and was ready to share that olive branch. Right up to the last paragraphs when you say (about me):

"...He keeps saying I propose 'a directory that gathers and holds ALL the data from ALL your other directories.' Dave, this is just untrue and unhelpful. “ALL” was never the goal - or the practice - of metadirectory, and you know it. The goal was to represent the 'object core' - the attributes shared across many applications and that need therefore to be kept consistent and synchronized if stored in multiple places. Our other goal was to maintain the knowledge about what objects 'were called' in different directories and databases (thus the existence of 'connector space').

Basically, the ”ALL” argument is a red herring..."

Not at all. Let's step back a pace or two, or a posting or two, and think about the reasons for having this meta/virtual directory. Yes, it helps to normalize the data and keep it in sync. But if that were all, than a couple of keyboard monkeys could handle the chore and, at least in the case of normalization, could do it more quickly than a semi-automated process.

But the real reason we want to do this is so that identity data is available to applications. Available to them using a single vocabulary and a single protocol. Not that there can't be multiple vocabularies and protocols, but any one application would only need to use one of each - each application programmer would only need to use the vocabulary and protocol she was most familiar with.

But for this to be effective, the programmer needs to know that any identity data they need is available through this mechanism. And the only way any data can be available is if all data is available. The identity data must be pervasive and ubiquitous - available whenever and wherever you need it.

From the application's point of view, it should appear to be a single silo but in reality, the data will be distributed throughout the fabric of the network both within and without the enterprise, the identity provider or other data store.

The promise of the meta/virtual directory is that it can serve up the current, correct data on demand from wherever it resides. And to do that, it has to aim to provide all identity data.

Now, to forestall some people, let me add that the security of this system is a given- there need to be strict and fine-grained access controls for the data. There need to be well designed mechanisms allowing for whoever controls a bit of data to authorize its release. Without these things the system is useless because no one would use it.

But this systems needs to aim to have available all identity data, every conceivable bit of it. Because without that, the application programmer can't be sure that the bit he needs is there and so will set up alternative storage for the bits that that application needs.

We're not there yet, but we need to go that way.

Labels: enterprise, IGF, metadirectory, virtual directory

Posted 9:58 AM (0) comments

Your mother was a hamster and your father smelt of elderberries!

Here I'd thought I'd offered Kim Cameron a bit of an olive branch in the virtual/meta/uber directory discussion. But did he take it? Yes, he did, then attempted to whack a bunch of folks about the head and shoulders with it!

In a further attempt to clarify what he meant, Kim says:

"By 'next generation application' I mean applications based on web service protocols. Our directories need to integrate completely into the web services fabric, and application developers must to be able to interact with them without knowing LDAP."

Why Kim feels that LDAP is beyond the ken of today's application developers is beyond me, but the darker part of this is that he seems to say that only through the use of the Microsoft-controlled WS-* protocols (you can read their propaganda at their web site) can this be achieved. Nonsense.

Still, if any developers feel that only XML based scripting is acceptable to use, then I'd suggest they consider the very good LDAP replacement, DSML which has, sadly, languished for a number of years. Or there's SPML (for provisioning services). Even XACML could be used (although it would need a bit more work). The point is that there are open protocols, openly arrived at, that will do the job and today's application designers are bright enough to know how to use them.

I'm reminded by Phil Hunt's post on this issue that his work on the Identity Governance Framework, now an OpenLiberty project, also satisfies the requirement of open protocols, openly arrived at.

Labels: IGF, liberty alliance, metadirectory, saas, virtual directory