This is my second post in a series looking at how federated identity has becoming a reality (I first looked at Twitter).

The user experience

The basic premise of federated identity is first you sign into something that you use a lot, and then the platform reuses that sign in to get you into other applications. Outside of the enterprise where people sign into their machines using Active Directory then by far the best place to start is email as that’s typically the app that’s opened first and used the most. Whenever I open my first browser after restarting a machine I open three tabs: Gmail, Google Reader and Google Apps mail for my company domain. In this case Gmail gives me a token to access all of the apps that are federated with my consumer persona, and GApps gives me a token for all of the apps that are federated with my work persona. When I start those other apps I might see some info in the browser saying that it’s redirecting briefly to Google, but I don’t see a sign in page, I get taken straight there.

First time

The first time you visit a site that supports Google sign in you’ll see something like this:

and then you get asked to confirm:

and after that things should be pretty seamless

Maintenance

You can review the applications using your Google ID by going into the My Account page and clicking on Change Authorized Web Sites [1]

Under the hood

There are two principle mechanisms at work:

1. OpenID for authentication

OpenID has been much maligned and is perceived to have many weaknesses. I would argue however that it isn’t a fundamentally weak protocol, and improvements have been made over time. I remember a few years back being stared at by a room full of identity geeks when I was the only one that said that I’d like the big company that was hosting us to support OpenID – oh how things have changed.

2. OAuth for authorisation

Sometimes authentication is enough in its own right, but there are many times when an associated authorisation is needed (e.g. to connect to contacts or calendar data). This is where OAuth comes in, and Google have been one of the driving forces behind the standard [2].

What about SAML?

The Google identity ecosystem, which has become the heart of Google Apps Marketplace is pretty much built on the ‘O’ protocols OpenID and OAuth, but there is a place for SAML. Basically it can be used to extend a Google based federation back into an enterprise – so first the user signs into their active directory or whatever [3] and then they get a Google issued token to sign into other apps. There’s a great diagram to illustrate how this works (thanks to Eric Sachs for pulling this together in the first place, and bringing it to my attention).

Persona

I already touched on the work/home persona piece above. Google certainly supports multiple personae, but there is trouble in paradise. A year ago I could be signed into multiple Google Apps domains, and my Gmail and everything behaved itself in isolation. These days I far too often see something like this:

and this:

and far too often when I select an account it still fails to get me to the right document. This can be worked around by using another browser (or ‘porn mode’), but it’s pretty aggrevating.

Google have tried to fix this with multiple sign-on, but this seems to do more harm than good. I for one don’t feel that offline mail is a sacrifice worth making.

The key issue seems to be that Google haven’t figured out an elegant means to determine an anchor identity against which multiple personae (more than 3 please) can be attached. For what it’s worth I’d argue that this should be put in the hands of the user – if they have multiple Google personae then let them decide which is the parent account (the one that they sign into first) and which are the children. Of course this can get complicated when work life (and work security policies) encroach onto ‘home’ computers and devices, which brings us on to…

Strong authentication

Had I written this a day or two ago as planned then I’d be spouting about Tricipher (and how wise VMWare were to buy them) and Verisign VIP (and how it also works with eBay/Paypal).

That all changed yesterday when Google launched their own two factor authentication.

I’ve been using it for a day now with the BlackBerry application, so some early thoughts on the system:

• It’s a shame that I couldn’t use an existing OATH token like the VIP soft token that was already on my BlackBerry [4].
• The access codes mechanism for applications and devices that can’t live with two factors is ultimately a security by obscurity mechanism for single factor by the back door, but I accept that it’s a necessary evil (I’ve already had to generate 6 codes). It would be helpful if I could impose additional controls (e.g. source IP) for certain access codes, but this is going to be impractical for mobile – bring on SIM/TPM based keys.
• Strike codes are a good catch all for when people lose their token generator, but I fear that much better education will be needed to prevent disasters here. At least there isn’t a weak workaround (like there is with the eBay/Paypal VIP usage when you say you lost/misplaced your token).
• User choice is all well and good for private accounts, but company administrators want control. I don’t want to say to my team ‘you can use 2 factor if you feel like it, it’s more secure but a bit less convenient’, I want to say ‘our corporate data is the life blood of the company, and we need to keep it as secure as possible – you will now need to use 2 factor’. I also want to have the tools to help my users out when they have trouble with 2 factor, like the ability for domain admins to (re)generate strike lists. It feels to me like Google have developed this for Gmail, but soft launched it to GApps Premier Edition.
• I seem to be being prompted for my password (not my OTP) more often than I was before I turned two factor on. This is making things like Postini a bit more clumsy to use[5], and providing a lumpy user experience. I’m guessing that some parameters have been tightened up, but it would be good to have control over this (and for the user experience to be a bit more evened out).

Overall

It mostly works most of the time, which is certainly better than the alternative of having dozens of passwords to wrangle. There is however clearly room for improvement, especially around the new two factor support and persona. Two factor is good, but it’s also a bit of a pain, so I want to be able to use it as infrequently as possible. For that to happen Google really needs to nail down this thing I’ve termed the ‘anchor account’, and provide a means to spawn various personae off from that.

Next instalment… Facebook.

Updates

Update 1 (19 Jun 2012) – Google have now enabled GApps administrators to force 2 factor authentication.

Footnotes

[1] for Google Apps for domains you need to got to https://www.google.com/a/yourdomain/ManageAccount to do this stuff.
[2] There’s some excellent documentation of OAuth here.
[3] It is invariably AD, though the sign in can be using whatever mechanism the enterprise chooses – password, smartcard, OTP etc. Sadly there isn’t a good way of seeing how strong the initial authentication was and passing that through to an eventual relying party.
[4] Sorry Joe, but it seems you’re out of luck – though there is a glimmer of hope from within the Googleplex. C’mon guys – tell us how it’s done?
[5] I got an error message about cookies, when what it really wanted me to do was sign in (again).