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:
- SAML web SSO profile involving an authentication request/response protocol
- Liberty ID-WSF identity mapping, discovery, authentication, and SSO services
- Identity selector interop profile done as a profile on top of WS-Trust
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.)
