Clemens and Gerry comment on a remarkable event: Microsoft shipping sample code…in Java…using a runtime stack the likes of which you have never seen before in a Microsoft product. It’ll be four years this week since the historic Sun-Microsoft agreement, and this sort of collaboration and proven interop is something the teams in both companies can really be proud of.
Sean McGrath reminds us of this ancient work from 2002; I think you’ll find it still has relevance and even poignancy today. Go you at once and read of the whole thing.
I tried to comment this morning on Dave Kearns’s post on my “identity bus” musings, but it hasn’t shown up for some reason, so I’ll say a few words here. (Later: Damn, how come I can never manage to say just a few words? Must…channel…Paul…)
I appreciate Dave’s confirmation of the overall goal; good to know I’m not crazy. But “going all Microsoft”?? :-) If I were advocating a particular protocol, I don’t even think that would be a bad thing, but advocacy of that sort wasn’t actually my intent.
I did observe that SAML tokens have had success at meeting one big criterion for an identity-bus-qua-message-bus. SAML tokens are used in lots of places, often with protocols other than SAML’s own. And when it came to another criterion, I “indicted” the SAML assertion query protocol pretty even-handedly with WS-Trust if they’re each considered all by their lonesome. While mentioning services of the sort that add helpful interop smarts (including ID-WSF ones), I even pointed out InfoCard as an great example.
If you choose a common data model for your identity layer, as many have done, there’s a whole bunch of “transform[ing of] protocols and data from one system and schema to another” you can avoid. In this sense, SAML’s “hub format” and a WS-Trust “hub service” are opposite approaches: the more you use an agreed-on format, the less you need transformations for the mere sake of syntactic conformance to another system’s needs. I will cop to advocating SAML2 tokens on this basis!
You might still need token exchanges for lots of other reasons, obviously. A quick test of whether you’ve got a nontrivial one: Would it still be useful for parties that use the same token format all around? In this case, I just observed that writing down those semantics will help get us to a successful identity bus. Imagine the chaos if you asked “RST?” and got any old “RSTR” back.
So, back to music and world peace! Yes, I admit it, I would like to teach the world to sing. But I must also admit that my accompaniment of choice would be (acceptable) piano or (really bad) ukulele, since guitar-playing is not among my skills…
While not jumping into the metadirectory catfight, I wanted to comment on this new metaphor that’s suddenly everywhere: the “identity bus”. The way it’s being used, I don’t get it.
I get that people would like identity information to be understandable across widely disparate systems, and that people would like services related to (deep breath) identity, authentication, attribute lookup, authorization, and auditing tasks to be widely available so that developers can concentrate on writing secure applications rather than security applications.
It’s fair to call this an “identity layer”. But that layer is more about semantics than about simple conveyance methods or syntax, because identity is way up in the stack. These aren’t random TCP/IP packets or HTTP messages, but information about us that we want our applications to understand and treat with care and consistency.
A “message bus” is a great metaphor to use in talking about this layer. But the very definition of a message bus includes rigorous semantics so that messages can be understood and acted on interoperably. The first Google hit I got for “message bus” was from this excellent definitional article on MSDN. The essential characteristics of a message bus:
- Uses a common data model
- Uses common command messages
- Uses a shared infrastructure
By contrast, take a look at this Network World article, in which Stuart Kwan offers what appears to be his definition of an identity bus:
“What is the finish line?” Kwan asked. “It is when you are able to take off-the-shelf applications and plug them right into the identity system and go. When we reach that point we are largely done with identity. It does not seem as far off as you might think.”
Kwan said what is needed are “transformers,” places where data contained within “claims” about a user can be into changed into different formats depending on an application’s need. Kwan said the transformers would be able to handle such things as Kerberos, X.509 certificates and assertions based on SAML.
This definition sounds like the “metasystem” all over again, a label that fell (or was mercilessly beaten :-) ) out of favor a little while back. I don’t think this will promote the identity layer we’re all looking for. What would satisfy the criteria for an identity bus, defined more formally?
The “common data model” of SAML assertions has done a lot to bring about the progress we’ve seen; its hub-format approach seems to have hit a sweet spot. The syntax choices it makes are its least interesting part for measuring interop; the most interesting part is the agreement among many parties on which piece holds authentication info, which has an attribute value in it, etc. To the extent that people have accepted and agreed on this data model, mere syntactic transformation between models has gotten relegated to a sort of legacy or vertical transformation up into the SAML-aware layer — something every SAML IdP does.
The “common command messages” that actually increase interop, going horizontally across the layer, tend to target specific identity- or security-related purposes. The generic SAML assertion query/request mechanism (did you know it had one?) is relatively uninteresting to a universal identity layer without further semantics, for the same reason that a generic WS-Trust STS is relatively uninteresting to this layer without further semantics. But we have lots of examples of higher-order services that do offer precisely defined semantics. Three obvious examples, among many others:
Wherever there’s interpretation or semantic judgment involved in a token issuance or transformation, and wherever it gets documented well enough that anyone can play, that’s added value in the identity layer. This value could apply to relatively simple X.509-for-SAML swaps too, but only if you document every nontrivial mapping somewhere — e.g., “where you see an attribute with this particular OID, always turn it into a SAML attribute that looks like this” or whatever.
(It could certainly be argued that things like the ID-WSF identity mapping service would benefit from “implementing a WS-Trust interface” in doing the job of semantic token transformation for its stated purpose, and I’d be receptive. But the value would seem to center on API consistency for developers’ sake, rather than actual interop.)
Harold Carr and team have continued their track record of excellence on Project Metro (which you might remember under the informal name Tango), a web services stack with superior interop in mixed Java/.NET environments.
Harold has shared the results of the latest plugfest, which took place on the Microsoft campus last week. He observes:
Note: our shipping product, Metro 1.0 (built into GlassFish V2 UR1 and runs in other web containers—e.g., Tomcat), interoperates with .NET 3.0 based on mostly non-standard specifications. What we tested at this plugfest was our current development codebase that will interoperate with .NET 3.5 based on standard specifications.
As you’d expect, lots of painstaking work has to go into this sort of work — congrats to the team on their great progress.
By the way, there’s gold in them thar hills if you’re working with Metro; check out Harold’s mention of the cool $175,000 (USD) award you can win.
So it’s not a pill
Does it awaken senses?
Sure as heck sounds cute
I’ve been really really busy, with tons of ideas for things to write about but precious little time to string together the minutes or the sentences. But I have to point you to this new paper that just came out, providing a technical overview of the Liberty Identity Web Services Framework (ID-WSF).
This makes a nice companion to the recent announcement about the open-source OpenLiberty-J work. The heart of the paper is sort of an index into the features and benefits of the V2.0 framework, taking various technical high-level requirements in turn:
Web Service Identity Model
A model is required for carrying the identity of the various parties associated with a transaction within the messages generated to invoke a web service. The parties potentially needing to be identified include:
- Sender – The party sending the message.
- …
and providing a guide to how ID-WSF meets the need and where you can find more info:
ID-WSF V2.0 defines the following components in support:
- A profile of WS-Security and SAML to carry the Sender, Recipient, and Invoking identities, as defined in the Security Mechanisms specification, the Security Mechanisms SAML Profile, and the Discovery Service specification (Section 2.3.3.5).
- …
I’m off to the airport shortly or I’d make those spec mentions into real links. Guess you’ll have to check out the paper itself to get those!
In the category of “things that make one feel old”: If you know what it’s like to have your heart race as the Space Invader blips speed up, or remember staking your claim to a game console with a big stack of real quarters, check out this wonderful series of performance-art projects that simulate arcade video games from the golden age.
I had seen the Space Invaders project video before, but only came across the others today. Back in the day, I played Tetris so much that I could close my eyes and play whole simulated games behind my eyelids. (Actually, I had no choice — it would happen unbidden.) I had an original Tengen version on my beloved NES and can still hum the Russian-y theme songs annoyingly on command.
And when my band indulges in some 12-bar blues jamming, I’ve been known to slip in the Moon Patrol theme. Ahem. Maybe that was TMI. But if you happen to be in Seattle on March 22nd and come see us play, feel free to request it…
I knew I’d get in trouble with my post on freshly baked identity events, by listing only five instead of a dozen! — so here are a few more baked goods to whet your appetite.
There’s the upcoming workshop where you can learn all about various Liberty Alliance identity standards on March 10 (that’s next Monday!) in Santa Clara, CA. There will be lots to chew on for both executives and technical architects, including descriptions of new open-source work, BOFs on hot topics (”currant affairs”, hee hee), and a discussion of Liberty’s work on aligning Levels of Assurance.
And of course there’s the RSA conference on April 7-11 in San Francisco, in which I have a particular interest because we’re holding a Project Concordia workshop/interop event on the Monday morning. If you’re going to the conference, I hope you’ll register for the (free) workshop as well. We’ll continue to gather deployers’ real-world concerns about multi-protocol interop as we’ve done at past events, and we’ll also demo some new interop scenarios that bring SAML2, WS-Federation, and InfoCard authentication a little closer together.
Finally, it’s not an event, but since it requires no traveling commitment you can consider it one of those cookie pieces that’s free because it has experienced caloric leakage: With my colleague Marina Sum I’ve put together a short article on the Sun Developer Network about federated identity and single sign-on from the deployer’s perspective. It’s a gentle introduction for web app owners on the prospect of “outsourcing” identity management tasks. If you’re new to single sign-on, check it out.