Superpatterns

Although I’m no longer as active in the OpenSSO community as I once was, some things still catch my eye – for example, news of a series of user group meetings across Northern Europe in late November and early December. OpenSSO experts Allan Foster, Jonathan Scudder, Steve Ferris and Victor Ake (not a blogger amongst them!?!?) will be presenting on OpenSSO-related topics ranging from monitoring to the Fedlet, via entitlements and OAuth, in Helsinki, Stockholm, Copenhagen, Oslo, London and Brussels. Seems like SupportRock might be a name to watch in the world of OpenSSO…

One question that repeatedly comes up in any discussion of web single-sign on is “How do I get my desktop apps to play?”. Often, Enterprise Single Sign-on (ESSO) is the answer – deploying an agent to the client desktop to automatically populate the username/password popup for Outlook, or whatever desktop app you’re working with. This has always felt a bit clunky to me, particularly since you need a credential store somewhere in the system, but it works well enough for the username/password case.

The ESSO approach breaks, however, if you’ve moved to a federated identity model, perhaps outsourcing your email to Google Apps and using SAML for single sign-on so that, instead of end users logging in to the email system directly, they authenticate to an identity provider (IdP) within your enterprise, which sends a SAML assertion (a signed XML document containing the user’s identifier and possibly other information) to Google as part of the web single sign-on process. Now the problem becomes: how do you use a fat email client such as Outlook, when (by design) Google knows nothing about the end users’ passwords?

Last week at Internet Identity Workshop 9 at the Computer History Museum in Mountain View, CA, Google presented an approach to this problem, leveraging OAuth as the glue between the web SSO world of SAML and the desktop view of Outlook. Well, they would have presented it, if the wifi had been more reliable; as it was, the Google engineers explained their solution to me

It works like this:

1. A Google plugin in Outlook intercepts the authentication process, obtains an (unauthorized) OAuth request token from Google’s OAuth service provider (SP) endpoint and invokes the browser with a SAML SP Google Auth URL, including the request token as a query parameter.
2. Google Auth invokes Google’s SAML SP, which redirects to the user’s enterprise IdP.
3. The user authenticates to the enterprise IdP (in the browser via whatever mechanism has been configured – typically username/password).
4. The enterprise IdP redirects to Google with a signed SAML assertion containing the user’s Google identifier.
5. Google returns a page for the user to give permission for Outlook to access their email; the user gives consent, submitting a form back to Google. This is the OAuth protocol step that authorizes the request token and permits an OAuth access token to be issued later.
6. Browser shows “Success” page.
7. Outlook plugin detects success (I guess it watches the window title), requests an OAuth access token from the Google OAuth SP (sending the, now authorized, request token), and uses the access token as the password in subsequent IMAP/SMTP/POP3 authentications with the Google mail server.

The OAuth consent page (step 5 above) seems a little clumsy, but, without it, if the user were already logged in to the enterprise identity provider, there would be no user interaction in the process, allowing a desktop app to obtain the OAuth tokens, and, thus, access to the user’s email account, without the user’s consent. Probably not a good thing

All of this is documented in the following articles at Google – many thanks to Eric Sachs for pointing me to the links:

• OAuth for Installed Applications – how to use OAuth to access Google Apps from a desktop app. The article doesn’t explicitly call out SAML, but, if you have enabled SAML on your Google Apps deployment, it gets used between steps 4 and 5 in the flow documented there.
• UX research on Desktop Apps using federated login and/or OAuth – an older article describing the approach taken by Google.

Note – I updated the flow above in light of more input from Eric at Google.

I'm currently reading 'Programming Amazon Web Services'

It’s the end of my second week at Huawei, and things are looking good. I’ve done a LOT of reading, getting up to speed on the non-identity parts of cloud computing, and we’ve spent some quality time around the whiteboard. I’ve also booked my first trip to Huawei’s headquarters in Shenzhen, which will be my first visit to mainland China (I went to a Liberty Alliance plenary meeting in Hong Kong a few years back).

One news item that caught my eye – Matt Bross (formerly BT’s CTO) has joined Huawei. BT has some very smart people, and it looks like Matt is no exception – I’m looking forward to meeting him when he visits the Huawei site in Santa Clara!

Talking of hiring, we’re still recruiting for the ‘virtual data center’ team – see Geoff’s blog entry – so, if you’re into large scale identity/security, storage, or systems and network management, drop me an email at  with your resume, the sooner the better!