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.

XACML and SAML – a Match Made in… 2005

Over at NetworkWorld‘s Security: Identity Management Alert, Dave Kearns weighs in on the ongoing federated provisioning debate with Federated provisioning could exist. While Dave is right to highlight the promise of the Liberty Alliance‘s Identity Governance Framework (IGF), he is way off the mark regarding XACML and SAML. Dave writes:

Some have suggested that XACML (eXtensible Access Control Markup Language) might be the answer. But it […] suffers from the same problem as SPML (no interaction with SAML) […]

This is patently not true! Four years ago, OASIS defined the interaction between XACML and SAML in SAML 2.0 profile of XACML v2.0 [PDF], part of the XACML 2.0 specification set. Since then, SAML/XACML has been implemented in a range of products, including Sun OpenSSO Enterprise, with interoperability between seven vendors’ products demonstrated at the OASIS XACML Interop Demo (held at the RSA Conference, April 2008).

XACML and SAML, best buddies since February 2005 🙂

Did You Know That Federated Identity Deployments Are More Secure Than You Think?

James McGovern asks the rhetorical question “Did you know that many federated identity deployments are insecure?”. I’ll leave James’ criticisms of OpenID and Cardspace to the respective experts, as I’m really only on the periphery of those communities, but let’s have a look at the insecurities he perceives in SAML-based federation…

James’ main point on federation is:

Many of the products will perform a lookup of the subject within a SAML assertion against an LDAP store […] So, if is a SP and supports multiple customers of which Credit Suisse is one and the other is say Goldman Sachs. would have a trust relationship with both of them but what would prevent a rogue Goldman Sachs employee from putting into their directory the subject (say email address) of a Credit Suisse employee and allowing it to be passed along?

There are multiple layers of protection against this kind of attack. The most obvious mitigation is the use of SAML 2.0 persistent identifiers. A persistent identifier is an opaque string (in practice, a long random sequence of characters, such as ZG0OZ3JWP9yduIQ1zFJbVVGHlQ9M that is shared by exactly one identity provider and one service provider to identify a given user. Now, let’s assume that our rogue Goldman Sachs employee manages to discover the persistent identifier of a Credit Suisse employee (difficult, since this value would only be shared between and Credit Suisse). On receiving a SAML assertion from Goldman Sachs, would look the user up with (Goldman Sachs, ZG0OZ3JWP9yduIQ1zFJbVVGHlQ9M), which would not match (Credit Suisse, ZG0OZ3JWP9yduIQ1zFJbVVGHlQ9M), so the assertion would be rejected. You can check out the OpenSSO source code to see how this works – persistent IDs are scoped to the (identity provider, service provider) pair, so you MUST use the identity provider when resolving them, since there is no guarantee that two identity providers won’t accidentally (or otherwise!) generate the same ID.

Can our rogue Goldman Sachs employee hack around with the assertion, to try to fool and get access to the Credit Suisse data? Well… he can try… Even forging every field in the assertion, without the Credit Suisse signing key, he cannot impersonate a Credit Suisse employee, since, ultimately, the signing certificate will not match that on file for Credit Suisse. Of course, it’s possible for an implementation bug to subvert all this careful specification work, as we saw with the Google/SAML vulnerability discovered last year.

Now, anyone familiar with’s implementation will be quick to point out that they don’t in fact use SAML 2.0 persistent ID’s, instead giving you the option of ‘Federation ID’ or Salesforce username. The former is an arbitrary string that the admin can set in the user entry at, so you could use this in the same way as a SAML 2.0 persistent ID. Let’s focus on the latter – Salesforce username, which is often, in fact, the user’s email address – James’ use case!

Now, let’s imagine our rogue Goldman hacker has set his email address to Well, the remainder of the assertion has Goldman Sachs all over it, so, assuming are using the assertion issuer name when they look up the email address, our hacker is still denied entry. And remember, we can’t forge the issuer name, since that will provoke a mismatch on the certificate. I clearly can’t see inside’s SAML implementation to check that they do match on the assertion issuer, but I can tell you that OpenSSO does exactly this. Again, SAML provides the framework to federate safely, but it’s down to you, the implementer, to get it right. And you can improve your chances of doing so by using an off-the-shelf implementation rather than rolling your own.

James’ other point on federation:

[…] federation products tend to be separate and distinct from web access management products. So, in this scenario the application wouldn’t even have an opportunity to protect itself as the federation product would simply create a cookie and not pass context as to how this user was authenticated.

Speaking for OpenSSO, we do not separate federation and web access management. You can assign an authentication level to SAML federation and use that in policy. Perhaps ‘level 1’ is SAML, ‘level 2’ is local username/password and ‘level 3’ is a hardware token; the ‘order entry’ app might specify level 2, while the ‘payroll’ app would specify that level 3 authentication is required. There are other ways of implementing this that spring to mind; segregating local and federated users into different domains for example, or testing some attribute in the user profile.

All good points from James, I have to say, illustrating the fact that, even if your wire protocol is secure, implementation issues can easily lead to vulnerabilities.

Slides and Blog Reaction from Tokyo Liberty Alliance Day 2008

Here are the slides [PDF] from my presentation at the Tokyo Liberty Alliance Day last month. The picture on the right is of the Microsoft speaker, Shigeya Tanabe, talking about Microsoft’s recent commitment to SAML 2.0, which he illustrated by a screen cap from my blog entry on the subject.

There was some blog coverage too, (all in Japanese):

I’ll be taking tomorrow off to extend the Thanksgiving break a little, so you’ll probably not hear from me until next week. To all those in the USA – Happy Thanksgiving!

Welcome, Microsoft, to the World of SAML 2.0

This is a blog entry I’ve been wanting to write for a LONG time… At the Professional Developers Conference today, Microsoft announced that ‘Geneva’, their forthcoming identity platform (part of which is the successor to Active Directory Federation Services), will not only support SAML 2.0 as a token format, but also as a single sign-on protocol. The Federation Wars are over!!!

Lots more to read on the subject:

Me, I’m looking forward to testing OpenSSO with Geneva. We live in interesting times indeed 🙂

SAML and Windows Login

Interesting post from James on the possibilities of Windows desktop systems being SAML identity providers (IdPs). Currently, a similar mechanism exists for desktop single sign-on from Windows (via SPNEGO, using Kerberos tokens, which, by the way, OpenSSO and Access Manager support directly, no IIS ‘bounce’ required), but this is limited to a single enterprise’s AD infrastructure and can be pretty tricky to deploy. It’s easy to imagine IE submitting SAML assertions to service providers at Internet scale in the way James describes. Microsoft seem to be reconsidering the case for supporting SAML 2.0, so they may even be receptive to something like this.

Where James does get things twisted (to use one of his favorite expressions 🙂 ) is in imagining that Sun and Oracle have much influence on our friends in Redmond. Microsoft’s paying customers have MUCH more clout than their competitors/partners. I’d suggest, James, that you band together with your peers at enterprises such as GM and Boeing, who I know, from their participation in Concordia, have very similar desires. Heck, you could even roll up your sleeves and dive right in to Concordia – it’s free, very enterprisey and Microsoft participate with open ears…

Single Logout with SAML 2.0 and PHP

Back in February, Marina Sum and I co-wrote an article on the OpenSSO SAML 2.0 PHP Extension, or Lightbulb, as it was then known. The sequel to that article – Single Logout: A Demo just went live at Sun Developer Network: Marina and I provide an update on Project Lightbulb’s evolution into an OpenSSO Extension as well as a look at circles of trust and single logout in SAML 2.0. As before, we look at a simple example message flow, then delve down into the PHP code to see how it all works. Click here for the article.