Superpatterns Pat Patterson on the Cloud, Identity and Single Malt Scotch

12Nov/098

SAML Single Sign-on with Desktop Apps – Enabled by OAuth

OAuth from Desktop App Diagram

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:

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

Comments (8) Trackbacks (0)
  1. Nice reading. Thanks for posting, Mr. Patterson.

  2. Pat, it seems the only connection between SAML & OAuth is in your Step 1, ie in which Outlook ‘invokes the browser with a SAML SP URL, including the request token as a query parameter. ‘

    What param is Google using for this?

    After this, SAML seems completely separable from the OAuth piece, ie its just how Google authenticates the user before authz.

    I’m also exploring mechanisms by which SAML protocol messages can carry Oauth params/tokens

    Paul

  3. Hi Paul – I’m not certain of the exact detail – there may be more coupling later in the flow. I’ll ask the Google guys if they’d like to clarify here…

  4. Word from Eric:

    There is actually no code in the OAuth enabled desktop that has any awareness of how federation or user-authentication happens at Google. In the generic case, the desktop app just tells Google it wants an OAuth token for “someones” mail/calendar API. In the more advanced case, it tells Google it wants an OAuth token for “someone in the domain acme.com.” That seperation/indirection is very powerful in our opinion because the user can be authentication using any means, and the federation (if it happens) can use any protocol/mechanism. So we don’t need to update the desktop app in the future if we add more federation mechanisms, or authentication mechanisms.

    I’ve amended my flow accordingly.

  5. I’d be very interested in more information, I’ve been looking for this for ages!

    Adam

  6. Hi Adam – All the information I have is in this blog entry. The linked articles at Google have some more detail; if you need more, you’ll have to get in touch with Google – Eric’s email address is on the page I linked to – http://eric.sachs.googlepages.com/

  7. hi Pat
    Doesn’t Microsoft do this with SPNEGO ? It will take credentials that I used to authenticate to AD (and thus from any “thick client” like Outlook) and make those credentials available in IE for browser based Auth?

    Jonathan

  8. Hi Jonathan – I think the key thing here is that you can use Outlook to access your mail at Google, whether or not Google has a password for you. It’s much more flexible.

    Yes, you can use SPNEGO to do SSO across Microsoft web infrastructure, but I don’t think it scales to thousands of IdP’s accessing an SP. To use SPNEGO, you would have to ‘kerberize’ the SP for all the IdP AD domain controllers, adding identities in each IdP’s AD and copying keytab files. Ugh!


Leave a comment

No trackbacks yet.