The Case for Federation and SSO

To date, the vast majority of real-world federation roll-outs have been internal or enterprise type deployments. Things like an enterprise authenticating its users out to an outsourced provider (such as a Fidelity 401K, or AOL's Radio Service). Yes there are many exceptions to this general statement (you can see many of them on Liberty's Adoption Page), but that is the general view of the industry and I certainly don't knowingly use federation in any cross-provider operations.

The time has come for federation and Single-Sign-On to be adopted in a more general fashion. I say this for many reasons and hope that the various vendors and providers out there will not be stubborn and/or resistant about it. I think this is valuable to parties that will wish to assert identity. I think this is valuable to the people who will accept identity federations and I think this is valuable to the users themselves.

When I say it is valuable to the user, I don't mean the often quoted "that way you can reduce the number of passwords you need to remember" -- though I still think that is a reasonable benefit. The real value for the user is that they will be able to share their data across multiple providers without the need to give their credentials to the other party.

Examples that already exist today include:

• On LinkedIn, if I want them to pull my contact information from my contact book in several mail services (e.g. GoogleMail, HotMa il, etc.) I have to provide LinkedIn with my username and password on the mail service. LinkedIn logs in as me (either through their web interface and does screen scraping, or directly via an exposed web service) and extracts my contacts. Since I gave them my login information, I'm hoping that they don't do anything wrong with the data (like expose it), and that they don't mis-use the access to my account (e.g. sending spam in my name).
• On Etrade, when I want to setup a new bank account for transferring funds from my Etrade account, one of the options provided is for ETrade to be provided with my username and password for online access to my bank account so that they can verify that I have control of the account and that it is in my name. Like LinkedIn, I'm hoping that they don't do anything wrong with the credentials while they have them (and in the case of ETrade, hoping that they do not store them like they claim they won't do).

I could go on with this list, but you get the idea. The user is already federating their data together across different providers. It's just in a very broken way that can lead to cascading security failures as any security failure at one site can lead to security failures at other sites.

With federation, I wouldn't need to give my credentials to LinkedIn. My mail provider could also differentiate the access provided (letting LinkedIn see the set of contacts that I chose to share with LinkedIn without being able to send mail in my name or being able to change contacts). LinkedIn could maintain that federation so that they could periodically check for updates. A break-in at LinkedIn would mean that someone could perform the same operations that I've already OK'd for LinkedIn -- get the data that LinkedIn already has -- so no additional exposure.

Why would GMail, HotMail, or even my bank, want to do this? First off, they are already doing it in an insecure way (I can always give my login credentials to the other party) and with the expanded access at their service. This would be a much better solution from a security and least priviledge point of view.

Another issue that might be raised with regards to the service providers is why would they want to expose a web service with this data. In many cases that's a new thing for them to do. But I think it's worth it becuase today, when they don't expose such an interface, theh other parties just walk though their standard user web interface and do screen scraping of the data -- I'm sure that data via a web page is more costly than exposing it through a programmatic web service.

Of course, LinkedIn would want to do this as they already do, but within the restricted capabilities of today that open them to some liability as well (should my data be misued at their site).

While I spoke heavily about LinkedIn in this post, this clearly applies to any and all cases where I want to do things across sites -- this is becomming more and more important in the Web2.0 world more interesting applications join togetether information from various parties. I can see how Dopplr would want to access my LinkedIn account to get my list of friends to pre-populate my traveling buddies rather than me having to establish new connections. I can also see how Dopplr would want to get access to my United Airlines itineraries so that they could auto-populate my trips.

The list goes on and on and it's a win-win-win for everyone, users and providers.

You might then have the decision as to what token format one should use for the federation and what web services structure one should use for the service access. I, of course, would recommend SAML and Liberty's Identity based Web Services Framework (ID-WSF), respectively, but that isn't as much the issue as is getting this up and running for the users.

You might notice that in this case, I haven't been advocating a large Circle of trust with centralized IdPs. Most of the examples I gave were point to point federations where, essentially, the relying parties and the IdPs were the same entity. The advantage with this model is that you have no need for extended business agreements so it's much easier to roll out. I do think that as more and more people start adopting and using this, it will be a natural evolution to environments where there are separated IdPs and Relying Parties, but we don't need to start there.

Tags : identity / federation / linked-in / ETrade / UAL / United Airlines / SAML / Liberty / Liberty Alliance / ID-WSF