Can't we just have a normal flat-screen?

Remember when everyone was getting excited (e.g. TechCrunch, Mashable, All Facebook) about Facebook allowing automatic login using OpenID? While they didn't accept just any OpenID, apparently a handful of well known OpenID providers would work. One of these approved providers was Google (using Gmail).

I dutifully linked my Gmail account to Facebook, logged out of Facebook, logged into Gmail, opened a new browser tab and navigated to Facebook. I waited. And I waited some more. I closed my browser and tried it again. I didn't think it would help but I suppose I was simply doing what Microsoft had programmed into my head from the many years of using Windows; when in doubt, reboot (I use a Mac now, so I wasn't going to go the whole hog and reboot my machine). It still didn't work. So now Facebook had a link between my Facebook account and my Google account without providing me with any benefit. I put it down to a bug or a misconfiguration but didn't care enough to persist. After all, I'd read that other people managed to get it working.

The keyword here is 'automatic'. Facebook's interface does not have a 'use your OpenID to login' link, hence it is important that it be automatic if they want to leverage an external mechanism like OpenID because there is no way for the user to initiate the sign on.

I revisited this supposed feature of Facebook recently because we were doing some testing with Facebook's supposed OpenID capabilities and after some investigation, realised it was still broken. That is, Facebook does not function as an OpenID relying party, even when using Gmail as the provider.

From what we can gather (by reading various bits and pieces), Facebook's auto-login relies on the existence of a browser cookie from its list of approved OpenID providers. In other words, it's a bit of a hack. Of course, they didn't have many other options as OpenID doesn't specify a way to perform automated checking for a user being logged into their identity provider. The obvious problem being that there are a multitude of potential identity providers and this can include ones that the relying party does not know about (side note: this isn't as much of an issue in an enterprise federated context because relying parties usually know where to redirect the user because there is typically only a single-trusted identity provider, which means the user gets automatic single sign-on if they are already signed-in to the identity provider).

I bring up automatic login and Facebook because I came across a rather interesting way that the people over at StackExchange (if you've ever visited StackOverflow, that's them) have chosen to tackle the issue across their network of sites: they are making use of HTML5 Local Storage instead of relying on crappy (and often insecure) browser cookies.

Reading between the lines, the issue they had was a common one many organisations run into. They have a network of sites that use separate identity stores and they wanted to be able to give their users seamless single sign-on while not compromising on usability. The stock standard answer from those in the vendor world would have been: "just use our Federated Identity Manager". Throwing SAML (I'll be referring to SAML throughout this post, but I really mean 'SAML or a similar open standard') at their problem would have worked. But they ended up rolling their own solution.

The open standards zealots out there would be chastising StackExchange for not using a well known, standard to solve their issue. But herein lies to the problem with what we refer to as Enterprise Federated Identity: it's too complicated for many situations. Unfortunately, a common issue is that OpenID on its own doesn't cut it.

StackExchange chose a hybrid model. They leveraged OpenID and layered additional security measures on top of it. While I haven't had the time to analyse their implementation in minute detail, they look to have designed a fairly sound solution. The obvious potential hole relates to how they store their data using HTML5 Local Storage, but at least it's an improvement on using browser cookies (because cookies are sent over the wire while HTML5 Local Storage stays on the client machine).

Of course, if StackExchange ever wants to federate with an external 3rd party, they're going to have to embrace SAML or force the 3rd party to conform to their home-grown solution (unlikely). But as long as their requirements remain within the realms of federating across internal sites, their solution should work.

The use case for federating internally within organisations comes up more often than not. And SAML always looks like a really simple solution when an architect is drawing it all up on a whiteboard. But wait until you talk to the poor grunts who have to make it all work and get their hands dirty (or until you see the invoice for the services).

I'm not advocating that everyone should roll their own federated identity solution. In a perfect world where costs and time are non-determining factors, we would all pick SAML. But we live in the real world and all I'm saying is I understand why organisations (like StackExchange) choose to disregard SAML. This also goes some way towards explaining why Enterprise Federated Identity hasn't taken off the way we all hoped it would. After all, the reasons to use SAML make sense right? Yeah but...

The well-known federated standards we have today are like:

1. A full-sized movie theatre screen (SAML and its variants)
2. A hand-held television (OpenID).

Many organisations simply need a decent sized flat-screen TV for the living room.