Posted 9:09 AM (4) comments

Smoke, mirrors - and numbers

RSA's Matt Flynn has been participating in the virtual directory/metadirectory conversation for some time, but his entry for today brings in more smoke and less clarity. Having been called out by Clayton Donley, Matt ripostes:

Also, it sounded like Clayton took my comments to mean that "everyone needs to be using Active Directory for everything", which was (I think obviously) not the intent. My point is that although the top 500 or 1000 companies may have a number of directories for various strategic uses, there are probably 20x that number of companies that use only Active Directory as the central and primary user store...

Now the problem here is in the numbers - the "top 500 ...companies" might harbor 5 million+ users. The "20x that number" (or, say, 10,000 companies) might total 50,000 users. Or, in other words, 1% of the total users are in all-AD environments, 99% are in heterogeneous situations. Which actually proves Clayton's point and refutes Matt's.

Additionally, of course, as long as most vendors (and most enterprises) make it so difficult to extend the schema of the central repository (whenever there is one) there will always be a need for a virtual repository for applications to use. The need for, and uses of, virtual directories is growing and is still a few years away from peaking.

Labels: FUD, metadirectory, virtual directory

Posted 6:02 PM (2) comments

A clueless manifesto

A big tip o'the hat to Jeff Bohren for drawing my attention to this note from Alex Karasulu of the ApacheDS project. Now remember, he's working on a Directory Server project. Yet he says:

The VD [Virtual Directory] implementations of today like Penrose, are just hacks without a formal computational basis to them. People trying to get a product to market rapidly to sell a company. We intend to enable virtualization eventually with a solid footing in the LDAP administrative model using this concept of a view. Views, as well as triggers/SPs will enable new ways to easily solve the problems encountered in the identity space. As a teaser just think what could be done in the provisioning space if AD supported triggers? Real technology will yield solid reliable solutions instead of these band aids we’re seeing during this identity gold rush.

Too bad he's not aware of Radiant Logic, Symlabs and the Oracle (nee OctetString) virtual directories - all of which have been around longer than ApacheDS and all of which support triggering mechanisms either through straight SQL or through policy implementations. They're pretty good with "views," also. I'm still looking for that "trigger" mechanism in the LDAP model!

Labels: FUD, metadirectory, open source, virtual directory

Posted 8:09 AM (0) comments

New tricks and old tools

Kim Cameron follows up on Clayton Donley's post with some thoughts of his own. And ends by quoting Clayton:

"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."

and adding: " As soon as applications understand they are PART OF a wider distributed fabric, they could propagate changes using a publication pattern that retains the closed-loop verification of self-converging metadirectory. "

I couldn't agree more with these two erudite gentlemen.

Unfortunately, today's applications, and especially yesterday's applications still hanging around on our networks, but even tomorrow's applications for some time to come won't be written to be a part of a "wider distribution fabric," especially as that fabric doesn't yet exist in any meaningful way. And, as Kim said in an earlier posting, "Here’s the problem. Infrastructure people cannot dictate how application developers should build their applications. " We can build the infrastructure that will excel in a publish-subscribe world, but getting the apps developers to buy in to that model, well, that's something else. I'm all for building the infrastructure and plumbing of the future, but we need to adapt today's tools so that we can get the job done while waiting for the new plumbing.

Labels: Identity Bus, Identity Hub, metadirectory, virtual directory

Posted 10:11 AM (2) comments

optimization and expense

Neil Macehiter comments on the last post:

But the issue is not with the language you use to perform the query: it's where the data is located. If you have data in separate physical databases then it's necessary to pull the data from the separate sources and join them locally. So, in Kim's example, if you have 5000 employees and have sold 10000 computers then you need to pull down the 15000 records over the network and perform the join locally (unless you have an incredibly smart distributed query optimiser which works across heterogeneous data stores). This is going to be more expensive than if the computer order and employee data are colocated.

The "expense" is there no matter how you do it. Putting all of your potentially useful data in one RDBMS is incredibly wasteful of storage space and comes at the cost of slowing down all queries. It also means that synchronizations need to be done almost constantly in order for the most up to date data to be available, a network "expense". But the search can be optimized before any data is pulled. For example, query the HR database for the lowest employee number issued after the first date you're interested in (assuming that employee numbers are issued sequentially). Then query the orders for PC purchases by that employee number or higher. Yes, it's two steps, but it's also faster than pulling down all the records to do a local join. And, I hold, less "expensive" than maintaining a huge silo of all potentially useful data.

Labels: Identity Bus, Identity Hub, metadirectory, virtual directory

Posted 8:46 AM (1) comments

Getting more violent all the time

The distinguished Mr. Cameron has restated what he thinks is our major disagreement over synchronization and replication of identity data on the so-called "identity bus." He says:

"Sometimes an application needs to do complex searches involving information 'mastered' in multiple locations. I’ll make up a very simple 'two location' example to demonstrate the issue:

'What purchases of computers were made by employees who have been at the company for less than two years?'

Here we have to query 'all the purchases of computers' from the purchasing system, and 'all employees hired within the last two years' from the HR system, and find the intersection.

Although the intersection might only represent a few records, performing this query remotely and bringing down each result set is very expensive. No doubt many computers have been purchased in a large company, and a lot of people are likely to have been hired in the last two years. If an application has to perform this type of query with great efficiency and within a controlled response time, the remote query approach of retrieving all the information from many systems and working out the intersection may be totally impractical.

Compare this to what happens if all the information necessary to respond to a query is present locally in a single database. I just do a 'join' across the tables, and the SQL engine understands exactly how to optimize the query so the result involves little computing power and 'even less time'. Indexes are used and distributions of values well understood: many thousands of really smart people have been working on these optimizations in many companies for the last 40 years."

What Kim fails to note, however, is that a well designed virtual directory (see Radiant Logic's offering, for example) will allow you to do a SQL query to the virtual tables! You get the best of both: up to date data (today's new hires and purchases included) with the speed of an SQL join. And all without having to replicate or synchronize the data. I'm happy, the application is happy - and Kim should be happy too. We are in violent agreement about what the process should look like at the 40,000 foot level and only disagree about the size and shape of the paths - or, more likely, whether they should be concrete or asphalt.

Labels: Identity Hub, metadirectory, virtual directory

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

Posted 8:55 AM (1) comments

The blind philosophes of Identity

Kim has now responded ("Through the looking glass") to my Humpty Dumpty post, and we're beginning to sound like a couple of old philosophes arguing about whether or not to include "le weekend" and "hamburguer" and other Franglais in the French dictionary.

We really aren't that far apart.

In his post, Kim recalls launching the name "metadirectory" back in '95 with Craig Burton and I certainly don't dispute that. In fact, up until 1999, I even agreed somewhat with his definition:

"In my world, a metadirectory is one that holds metadata - not actual objects, but descriptions of objects and their locations in other physical directories."

But as I continued in that Network World column:

"Unfortunately, vendors such as Zoomit took the term 'metadirectory' and redefined it so it could be used to describe what I'd call an überdirectory - a directory that gathers and holds all the data from all your other directories."

Since no one took up my use of "uberdirectory," we started using "metadirectory" to describe the situations which required a new identity store and "virtual directory" for those that didn't.

So perhaps we're just another couple of blind men trying to describe an elephant.

Labels: Burton, identity, metadirectory, virtual directory

Posted 4:00 PM (0) comments

Get on the bus!

Everybody else is. Dale Olds has commented. So has Phil Hunt. Let's all get together at the European ID Conference in Munich later this month and talk about the Identity Hub, the Identity Bus, the death of the metadirectory and so much more. Suggestions for a suitable meeting place (i.e., biergarten) near the Deutsches Museum are welcome - post as comments to this post.

See you there!

Labels: EIC, Identity Bus, Identity Hub, metadirectory, virtual directory