Posted 11:01 AM (0) comments

Buzz phrase du jour

Came across another, to me, really dumb term this morning: Private Clouds. I'm still not all that comfortable with "cloud computing," mind you. Differentiating it from last year's Software as a Service (SaaS) where the service is outsourced presents issues to me - issues of why call something a new name when the old one works just as well. So too with this oxymoron "Private Clouds". The author starts by appropriating (from the Berkeley RAD Lab's cloud computing report) a definition of cloud computing. Of course, he goes on to state "...that the RAD Lab specifically states that they do not consider internal (i.e., private) clouds to be 'real' clouds..." This doesn't stop him, though and he blunders on.

Perhaps I just understand this part better, but his comments on Identity Management left me chuckling:

"A robust identity management system needs to be in place to enable automation. Requests for computing services will come not from a sit-down meeting where authentication and authorization will be done on a personal basis - i.e., direct face-to-face interaction enabling the resource granter to identify the legitimacy of the request and the requestor - but from an service request via a software-enabled mechanism like an internal portal."

Ask any mid-sized to large enterprise IdM manager when was the last time that provisioning was done via a "direct face-to-face interaction"! Automated, even self-service, IdM has been around since long before the "cloud" paradigm was ever contemplated and its use does not constitute evidence of the elusive "private cloud" architecture, but of a robust enterprise IdM system.

Calling a POCS (Plain Old Client-Server) system a "private cloud" simply because you've added some self-service elements succeeds only in muddying the waters at a time when clarity is needed. Let's agree to drop this foolish term.

Labels: cloud, rant, saas

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:14 AM (0) comments

It's unsanitary, Kim!

In a blog entry today, Kim Cameron both puts words in my mouth and twists the ones that come out to serve his "straw man" purpose.

In commenting on my recent post about the death of the metadirectory, he says: "Who would want to get in the way of Dave’s metaphors? He’s on a streak. But he’s making a fundamental mistake, taking an extreme position that is uncharacteristically naive."

What did I do? I advocated the virtual directory as the better vehicle for all of the ID data needed in the SaaS world.

Kim implies that, somehow, I called for the virtual directory to be authoritative. That's simply not so. the virtual directory is merely the conduit to the authoritative source, wherever it might be. The application developer doesn't even need to know the authoritative source of the data - or need to re-write code if that source changes.

But then he goes on to say: "Application developers like to use databases and tables. They have become expert at doing joins across tables and objects to produce quite magical results. As people and things become truly first class objects in our applications, developers will want even more to include them in their databases."

I couldn't agree more. As a developer, I always prefer to have a local cache of the data I need in a (for me) easily manipulated data structure. But that does not mitigate against the use of a virtual directory. Far from it. The application database (for those who cling to it like Linus and his blanket) now can serve two purposes - one to subscribe to virtual directory data and one to publish!

The application database is the authoritative source of the application-generated data, and should be linked to the virtual directory which will consume this data and make it available for other applications and services. At the same time, any data which the application consumes - but which it is not authoritative for - can be populated at run-time from the virtual directory. For the developer who thinks this is a performance hit (and for whom accuracy is less important than an extra millisecond), a "synchronization stored procedure" would handle data changes without stealing precious time from the user-application interaction. It really is win-win.

Now the argument could be made that a synchronization engine (such as in a provisioning system) could periodically update all of the various datastores with any new or changed identity data, but that simply takes the well-known synchronization problems of the metadirectory and magnifies them by the dozens, hundreds or thousands of application datastores within the organization. That's a recipe for disaster. If an individual developer, for an individual application, wishes to sacrifice accuracy and risk the potential of error caused by out-dated data, or data whose location has changed in the hope of a spurious speed improvement (almost immediately unnoticeable due to the fluctuating nature of network thruput), they'll quickly learn, I believe, that "haste makes waste."

The further error Kim makes, though, is to believe that a virtual directory can't look like a SQL database to the application (or an XML database for web services developers). The folks at Radiant Logic would certainly disagree. It's all about the context. I'd invite Kim, and other skeptics, to our sessions on Identity and Context (including one about context and user-centric identity, as well as context and virtual directories) at next month's European Identity Conference in Munich.

Labels: EIC, saas, virtual directory

Posted 8:00 AM (0) comments

Killing the Metadirectory

Kim Cameron comments today about my column ("Is the metadirectory dead?") which was inspired by Kim's erstwhile colleague Jackson Shaw's blog entry ("You won't have me to kick around anymore!") which included the lines: "Let's be honest. The meta-directory is dead. Approaches that look like a meta-directory are dead."

My interpretation is that the metadirectory has finally given way to the virtual directory as the synchronization engine for identity data. Kim interprets it differently. He talks about the "Identity Bus" and says that "...you still need identity providers. Isn’t that what directories do? You still need to transform and arbitrate claims, and distribute metadata. Isn’t metadirectory the most advanced technology for that? " And I have to answer, "no." The metadirectory is last century's technology and it's day is past.

The Virtual Directory, the "Directory as a Service" is the model for today and tomorrow. Data that is fresh, always available and available anywhere is what we need. The behemoth metadirectory with it's huge datastore and intricate synchronization schedule (yet is never quite up to date) are just not the right model for the nimble, agile world of today's service driven computing. But the "bus" Kim mentions could be a good analogy here - the metadirectory is a lumbering, diesel-spewing bus. The virtual directory? It's a zippy little Prius...

Labels: saas, standards, virtual directory

Posted 4:56 PM (0) comments

Identity as a service

An interesting post today, from Jonathan Penn at Forrester. For the most part he's quoting his fellow analyst, Andras Cser, but does through in his own two cents worth in agreeing with Cser's definition of Identity as a Service (IDaaS):

"...implementing identity and access management functionality predominantly as Web services in a service oriented architecture within the enterprise. Various line of business applications, policy management applications, and other services then call these IM Web services either autonomously or in an choreographed manner."

I also would like to jump in with a big "+1" for this definition. It's what I was thinking of when I said about Microsoft's CardSpace: "I'm addressing the enterprise market, which needs to pay attention to CardSpace right now. Many of your in-house developers are already using the .Net framework and Microsoft's Visual Studio to create and maintain your in-house apps and services. Handling authentication, though, has been difficult at best. Now a hero has ridden forth."

Software as a service (SaaS) is going to come first to the enterprise, and IDaaS is going to be a major enabler of that technology. And CardSpace (and the associated iCard open source technology) will be the major building block of that foundation.

Labels: cardspace, digital identity, enterprise, saas