Multi-protocol Identity Implementations

Interesting to see the discussion over the past few days between Phil Windley and Johannes Ernst on multi-protocol identity implementation. I’ve been through a couple of iterations of this myself, with last year’s Microsoft/Sun Web SSO specifications and the Burton Catalyst multi-protocol federation demo.

There is a complex dynamic between identity providers supporting many protocols to service a wide range of relying parties and the converse, relying parties supporting many protocols to allow users to authenticate at any one of a range of identity providers. In the B2C world, it seems likely that the role of identity provider will naturally gravitate towards the big guys - maintaining a secure identity infrastructure is expensive - scale provides natural economies. This would seem to indicate that identity providers will be able to dictate terms - “My way or the highway”, but we haven’t seen much evidence of that. On the contrary, identity providers seem to be the ones interested in multi-protocol support at their end - the multi-protocol identity provider hub model that we demonstrated with Access Manager at Catalyst.

The logic is that, once you have an infrastructure for storing identities and authenticating users, supporting 2, 3 or 4 protocols isn’t much more difficult than supporting 1. The relying party is in a different position - their core business is the service they are providing - horoscopes, online gaming, a blogging platform, whatever. The relying party wants to pick a protocol, implement it with identity provider #1 and add identity providers over time without a bunch of extra expense and complexity.

On the other hand, in the B2B arena, the dynamics may turn out to be the reverse, as relying parties (service providers) such as 401(k) providers, health benefits providers and even political action committees implement federated SSO to allow company employees to leverage their enterprise login to access external resources. Here, the relying party may take the driving seat, implementing a range of protocols as they implement federation with a range of their customers. Enterprises are deploying federation internally first, hooking up divisions, so when a service provider offers federated SSO the identity provider is likely to have already selected a technology.

Caveat - this is a rapidly evolving market (who would have foretold the explosion in user-centric identity?) and the above is based on the observations of one guy talking to a random bunch of enterprises and organizations. I’m perfectly prepared for a bunch of incoming links over the next few weeks/months/years explaining just how wrong I was