Overlap of identity technologies

Have you ever wondered how all the following technologies fit together:

OAuth, OpenID, SAML, XRDS, SaaS, Strong/2ndFactorAuth, InformationCards/CardSpace, OpenSocial, Portable Contacts, WS-*, Geneva, ...

Because the technologies are evolving, and do overlap in some cases, they can fit together in a few different ways. The goal of this document is to give some examples of how the technologies fit together. There will be some debate over the pros/cons of overlapping technologies such as OpenID/SAML as well as different forms of Strong/2ndFactorAuth, and certainly the full scope of InfoCards could overlap with almost all of these. But as the adoption levels of these technologies increase, we will identify the different use cases where one technology fits better then another, and that should help companies decide what combination of technology best meets their need.

Example 1: An "almost" real world example

Lets say that Tom Brown works at the company AlertBlue which outsources their E-mail to Google Apps Premier Edition. Alterblue has setup a corporate single-signon system and uses InformationCards as a second factor of authentication.

Tom would like to register for LinkedIn to manage his business contacts, but he wants to keep his contacts synchronized between the corporate E-mail system and the LinkedIn service.

Here is a diagram of how the flow could work:

Here is a more detailed description of the steps.

• 1. Tom arrives for work one day, and before he logs into the corporate SSO system, he decides to setup a LinkedIn account using his tom.brown@alertblue.com E-mail address and providing a password that he wanted to use for the account. (In Example 2 below we talk about this step could be optimized in the future)

  2. During the setup process, he provides his E-mail address to LinkedIn, and the LinkedIn servers make an inquiry in the background using XRDS to ask AlertBlue's servers if they support the Portable Contacts standard, and they respond with a yes. (This discovery step is invisible to Tom)

  3. Tom is then redirected via the OAuth protocol to the server that AlertBlue specified via XRDS that supports PortableContacts for their domain. Since AlertBlue has outsourced E-mail (and contact lists) to Google, the XRDS file actually points to Google's servers, so Tom is redirected there. (This discovery step is invisible to Tom)

  4. Google recognized that there is a request to access the E-mail of an AlertBlue employee, however it determines that AlertBlue runs its own corporate SSO system, so it redirects Tom back to that system using the SAML protocol (This federation step is invisible to Tom)

  5. Tom now sees his corporate SSO login system. That SAML IDP might be run using Microsoft's Geneva framework on top of Activity Directory, though other SAML platforms also exist.

  6. The SAML IDP might authenticate him using a strong authentication mechanism, and one such mechanism is InfoCards. The IDP can make an automated request to his computer to confirm it has the special security software (Information Card Selector), otherwise it prompts him to download & install that software. Tom's computer then uses that software to request his consent to send that InfoCard to the corporate SSO system (Though after Tom has done this once, he might choose for it to happen automatically in the future so it will be invisible to him)

  7. The corparate SSO system validates his InfoCard, and then use SAML to redirect the user back to Google and assert that the current user is in fact Tom. (This federation step is invisible to Tom)

  8. Google validates the digital signature in the SAML response, and then logs Tom into Google Apps Premier Edition (This key/token management step is invisible to Tom). Note that AlertBlue would have previously used a provisioning API to create a user record at Google for their employee Tom.

  9. Google has remembered that it received a request from LinkedIn for the user's Portable Contacts. Google therefore displays a page to Tom asking for permission to make his contact list available to LinkedIn. (Though after Tom has done this once, LinkedIn will have ongoing access to his contact list unless Tom goes to his account settings page to revoke that access). Here is an article with examples of the type of user interface used for this OAuth approval

  10. Google now redirects Tom back to LinkedIn using OAuth and sends a special token that can be used by LinkedIn in the future to access Tom's data. (This is invisible to Tom)

  11. LinkedIn saves the OAuth token. (This is invisible to Tom)

  12. Now LinkedIn loads its OpenSocial software (based on the open source Shindig project) and loads the subcomponent that handles the Portable Contacts data format. (This is invisible to Tom)

  13. LinkedIn now makes a request to Google with the OAuth token and asks for Tom's contact list using the Portable Contacts data format (This is invisible to Tom)

  14. Google returns the requested data, and LinkedIn uses that information to update Tom's business contact list in LinkedIn (This is invisible to Tom)

  15. LinkedIn now shows a page to Tom confirming it has access to his E-mail contact list, and it automatically notifies him of existing LinkedIn users on his list who already have him in their list of contacts. Tom is given the option to add them as LinkedIn contacts, as well as the option to send invitations to his other contacts.

A key thing to note is that between steps 2 and 15, all Tom sees is one screen to enter his password, and one screen to approve LinkedIn's access to his data. If Tom had already been logged into this CorpSSO system before starting this process, then the ONLY page he would have seen was that approval page.

This example is not made up. The pieces are available today, and the first company to put a lot of those pieces together is Plaxo who follows this process for users in the @gmail.com domain.

However there is one step I skipped over. In Step 1 when I said he had to "setup a LinkedIn account" he had to go through the traditional annoying process of creating a password and providing his name, country, zipcode, company, & title. So to simplify that part, lets move to example 2.

Example 2: What the industry hopes is coming soon

Lets say that in addition to Google running the E-mail system for AlertBlue, it also ran an "identity provider" that employees could use to assert their identity to other websites on the Internet. So lets go back to step 1 above and see how that might work:

• 1. When Tom decides to signup for LinkedIn, he goes to their website

  2. They have a login box that asks for his E-mail address, and then gives two choices. One is to enter his LinkedIn password if he has one, and the other is gives him the option to get "help to sign in," so he chooses the second option. Here is an article with examples of that type of federated login interface, though the OpenID community is working on other UI guidelines for a broader set of use cases.

  3. LinkedIn extracts the domain of the E-mail he entered, and makes an XRDS inquiry in the background to ask AlertBlue's servers if they support the OpenID standard, and they respond with a yes. However, as part of that "yes" response, AlertBlue tells LinkedIn that Google runs the OpenID "identity provider" for AlertBlue. (This is invisible to Tom)

  4. LinkedIn then checks the list of "identity providers" that it believes provide a high reliability service with a good user interface, and it finds Google on that list. (This is invisible to Tom)

  5. Tom is redirected to Google via the OpenID protocol with a request for two pieces of his identity information. The first piece is his E-mail, and the second piece is a computer generated URL that AlertBlue & LinkedIn will agree to use when communicating about this user in the future. (This is invisible to Tom)

  6. At this point, Tom might not be logged into Google or his CorpSSO system, in which case he would go through steps 4-8 above.

  7. Once his identity is authenticated by his CorpSSO system and he is logged into Google, then Google will display a page to Tom asking for permission to sign him into LinkedIn and send them his E-mail address and first/last name. Here is an article with example of the type of user interface that an IDP would display.

  8. Once Tom gives his approval, Google will send him back to LinkedIn using OpenID to transmit his identity information. (This is invisible to Tom)

  9. LinkedIn creates an account for Tom on the fly, and determines his company name from his E-mail address.

  10. LinkedIn now asks Tom to agree to their Terms of Service, as well as for his country, zipcode, and title.

  11. Now Tom would go through steps 9-15 above

Let's review the screens he would see if we combined example 1 & 2:

• 1. LinkedIn login page

  2. AlertBlue CorpSSO login page (and Information Card page if he had not already configured his InfoCard to be sent automatically)

  3. Google approval page to share his identity with LinkedIn

  4. LinkedIn page that asks for country/zip/title and shows the LinkedIn TermsOfService

  5. Google approval page to share his PortableContacts with LinkedIn

  6. LinkedIn page to confirm his account is setup and ask him to invite his contacts to use LinkedIn

Notice that steps 3 & 5 are currently separate, and use different protocols (OpenID for step 3, and OAuth for step 4). However Google supports a hybrid method to combine these protocols into one step. That allows Google to show a single approval page for both purposes, and then we would be down to 5 steps.

However, LinkedIn has subscription services, so AlertBlue could have chosen to purchase an enterprise license that allowed all their employees to access premium services from LinkedIn. In that case, the owners of AlertBlue could ask Google to automatically approve all OpenID/OAuth requests by LinkedIn for their employees identity and contact information using a variant of OAuth which Google supports called 2-legged OAuth. That now brings the number of steps down to 4:

• 1. LinkedIn login page

  2. AlertBlue CorpSSO login page (and nformation Card page if he had not already configured his InfoCard to be sent automatically)

  3. LinkedIn page that asks for country/zip/title and shows the LinkedIn TermsOfService

  4. LinkedIn page to confirm his account is setup and ask him to invite his contacts to use LinkedIn

Steps 3 & 4 could be combined, so that leaves us with 3 steps.

In step 1, the only piece of information LinkedIn really needs to know is that the user is from the @alertblue.com domain. The OpenID community is already discussing ways (such as the one in this article article) to standardize a method for the user's identity provider to be detected invisibly (once the user has given their consent for the sites they visit to have access to that information). In that case, it is possible that when Tom visited the LinkedIn site, instead of a login box he was given the option to select his preferred identity provider along with an advanced option to switch back to the regular login box.

In the normal case, Tom would have already been logged into his CorpSSO system when he first logged into his corporate computer, so in that case, all he would need to do is go to the LinkedIn site and click AlertBlue as his identity provider. The rest would then happen invisibly to him and all he would see is the LinkedIn page with the TermsOfService and confirmation his account is ready.

Again, this example is not made up. The pieces are available today, and the first company to put a lot of those pieces together is Plaxo who follows this process for users in the @gmail.com domain. The success of this approach was first announced in Feb 2009 in what is being called the "92% demo."

Two other problems

While the industry is close to being able to make this type of scenario work, there are still some problems that remain. Two of the trickier known issues are the following:

• • Strong/2ndFactorAuth on shared computers and mobile devices

  • Rich-client apps on PCs, mobile devices, TVs, etc.

In the example above, we described the use of InfoCard technology as a second layer on the employee's computer to identify them. While this software can help protect against phishing, it might not be present on a shared computer such as his parent's home computer (or a web cafe) where Tom might want to check his corporate E-mail. There are other forms of Strong/2ndFactorAuth that are more portable, but have different security characteristics. Here is an article with usability notes on strongauth.

That then leaves the problem of rich-client apps, such as desktop applications and applications installed on mobile phones. It takes much longer to update applications that have already been deployed to lots of users, as opposed to just updating a website. Most existing rich-client applications authenticate users by asking the user for their username/password, and then transmitting that to a web server to identify the user. However, in the examples above, any such desktop apps written for LinkedIn or Google would not work, because neither LinkedIn or Google has Tom's password, only AlertBlue has it. And worse, AlertBlue does not authenticate Tom by just asking for his password, they also need a StrongAuth device. Fortunately the OAuth protocol does define a technical standard by which a rich-client app can launch a web browser, and request the user's permission to access their data. Once the web browser has been launched, then other protocols such as OpenID & SAML & Strong/2ndFactorAuth can be used to authenticate the user as described above. However the use of OAuth with rich-client apps has not really been used because of usability problems, and the lack of open source libraries for mobile devices and other specialized devices like Tivos & AppleTVs that are starting to become more popular. Fortunately the OAuth community is doing more research in this area and is making progress. Unfortunately, even once we "solve" this problem, this part may take the longest to get deployed because of the difficulty in updating client software on desktops and mobile devices.

Summary:

At the risk of being shot for "stereotyping" all the technologies above, the following is an attempt to give a short list of these technologies, and where they fit:

IDENTITY ECOSYSTEM LAYER

• • XRDS: A method for a Internet domain to advertise the different web services it supports (such as PortableContacts or OpenID), and the configuration details for how to interact with that particular web serice. XRDS information can also be use to published metdata details about a specific URL (such as an OpenID URL).

  • OAuth: A method for a website (or rich-client app) to request access to a user's private data stored at another website, along with standard for the first website (or rich-client app) to send the user to the second website to grant approval for that request (unless a domain admin had previously approved it)

  • SAML Web SSO: The "Web SSO" profile of SAML is commonly deployed protocol in enterprises/ISPs/schools/etc. to allow users to login once, and automatically be able to authenticate to other systems both within the organization, and externally. More generally SAML is an XML-based framework for identity assertions & protocols, such as Web SSO, but also SOAP web service security tokens.

  • OpenID: A technology similar to SAML Web SSO, however with a particular emphasis on (1) the usability of getting the user's approval to share their identity, (2) allowing and RP & IDP to interact even if they have never previously communicated, (3) a universal way to identify a user that avoids two "identity providers" identifying two different people with the same identifier, and (4) allowing the user and/or domain to delegate their IDP functionality to a another website that runs the IDP technology as a service.

  • WS-*: A standards based stack for providing interoperability for API interaction between web servers. It is primarily used with SOAP based APIs in Enterprises, wherease most REST based APIs do not leverage the WS-* stack. However the REST community is building standards like OAuth and XRDS on top of REST APIs which provide similar functionality to that of the WS-*.

• Microsoft Geneva: Microsoft's .Net server and client components based on WS-* and SAML. Geneva was announced in November of 2008.

  • Strong/2ndFactorAuth: The general concept of authenticating a user with more information then just a password. That information could take many forms such as looking at their IP address and cookies (as online banks are starting to do), or issuing tokens (as PayPal offers), or calling their phone, or biometric devices (government/military), or installing X.509 certificates, or deploying InfoCards, etc. Any login system, or federated login system like SAML/OpenID, has the potential to be extended to support strongauth.

    • Certificates: One form of Strong/2ndFactorAuth based on software or devices that use advanced security techniques called cryptography to help identify the user in a way that protects against many forms of phishing.

    • Information Cards: Another form of Strong/2ndFactorAuth. At its most basic form, it is a software certificate available on computers with special software. It was originally developed by Microsoft and has the capability to support other advanced technical features. However, unlike all the other technologies listed above, it requires special software to be installed and configured on the user's device, and thus is harder to deploy as widely as the existing installed base of web browsers.

    • Microsoft CardSpace: The specific implemention of Information Cards that Microsoft provides for the Windows operating system. Other implementations of Information Card components include Novell Bandit’s DigitalMe™, Higgins, OpenInfoCard, CardPress™, Azigo™, and so on. There is also the non-profit Information Card Foundation

IDENTITY "CAMPS"

There are roughly two "camps" in the identity space, "Enterprise" and "OpenSource."

• • The group with the most experience is the "camp" that is more Enterprise focused, and has been developing technologies such as SOAP, SAML, Liberty ID-WSF, & WS-* for many years. There are many enterprise vendors in this space who provide software that supports these technologies.

  • The "OpenSource" camp is newer, and has primarily focused on building REST based protcols (such as OAuth & OpenID) that are available with open source implementations on many platforms. However as these technologies have evolved and added functionality, that added functionality has made them look similar to the WS-Trust & SAML protocols. Most of the major SaaS vendors (Amazon/Google/Salesforce/Yahoo/etc.) have taken this approach because they provide additional features that better supported consumers, small businesses, and "mashup/web2.0" developers. Those SaaS vendors are now heavily involved in designing/evolving these technologies to ensure they could be scaled in a highly reliable manner on their infrastructure.

It is unlikely that the "OpenSource" camp will replace the "Enterprise" camp any time soon because of the large number of existing systems leveraging the "Enterprise" identity technologies. However software/services like Microsoft's Geneva/Azure are making it easier to bridge the gap between the two "camps" and the general industry movement to "web services" is leading to much more momentum in the "OpenSource" camp.

Eric Sachs, Product Manager, Google Security

Ashish Jain, Ping

Paul Madsen, NTT