Information Cards for Google Apps

Information Cards are an industry standard that enable people to maintain a set of personal digital identities.
Information Cards are like cards in your wallet. Each one defines a relationship between you -the cardholder- and the card issuer -the identity provider. They provide a way to transfer claims/attributes from the identity provider to a relyingparty. Information Card selectors are available for all major operating systems and major browsers. To learn more about Information Cards please visit the Information Card Foundation.

Having provided support for "SAML Single Sign-On (SSO) Service for Google Apps" not so long ago Google is now proud to present support for Information Cards for Google Apps.
The step from "SAML Single Sign-On (SSO) Service for Google Apps" to Information Card support is actually quite small. This is due to the fact that all Information Card selectors are token agnostic that is: They don't care which type of token is transfered from the identity provider to the relying party. Therefore we choose to use SAML assertions that are used in "SAML Single Sign-On (SSO) Service for Google Apps" too.

Security Assertion Markup Language (SAML) is an XML standard that allows secure web domains to exchange user authentication and authorization data. Using SAML, an online service provider can contact a separate online identity provider to authenticate users who are trying to access secure content.

Google Apps offers an Information Card based claims transfer that provides partner companies with full control over the authorization and authentication of hosted user accounts that can access web-based applications like Gmail or Google Calendar. Using the Information Card model, Google acts as the relying party and provides services such as Gmail and Start Pages. Google partners act as identity providers and control credentials and other information (claims/attributes) used to identify, authenticate and authorize users for web applications that Google hosts. Google wants to point out that it is hard to overestimate the security gains for our partners. By using the authentication methods implemented in e.g. Windows Cardspace partners can use Kerberos, X509 and self-issued cards to authenticate the user to the security token server; thereby leveraging existing corporate infrastructure to access Google Apps through this new services.

There are a number of existing open source and commercial identity provider solutions that can help you implement Information Cards with Google Apps.
It is important to note that the SSO solution only applies to web applications. If you want to enable your users to access Google services with desktop clients such as Outlook—for example, Outlook would provide POP access to Gmail—you will still need to provide your users with usable passwords and synchronize those passwords with your internal user database using the Provisioning API.

The Google Apps with Information Card is based the "Identity Selector Interoperability Profile V1.5". Information Cards are supported by several widely known vendors. Visit the Information Card Foundation to learn more.

Understanding Information Card based usage of Google Apps

The following process explains how a user logs into a hosted Google application through a partner-operated identity provider service.

Figure 1: Logging in to Google Apps using Information Cards


This image illustrates the following steps.

1. The user attemps to reach a hosted Google application, such as Gmail, Start Pages, or another Google service.
   Google presents a page with the purple-i that denotes that Information Cards can be used here. The RelayState parameter containing the encoded URL of the Google application that the user is trying to reach is transferred to the Google ACS as a form parameter. This RelayState parameter not transferred to the partner. Each google app requests at least one claim that is identitcal to the applications base url e.g. "http://calendar.parityapps.com/".
2. The user clicks the purple-i icon
3. The cardselector starts and the user selects her information card e.g. the managed card issued by Parity. The card selectore sends the security token request to the partner
4. The partner parses the request and authenticats the user using one of the supported authentication methods Kerberos, X509 certificate, self-issued card or username and password
5. Partner generates SAML assertion (security token).
6. The browser posts the security token and the other form element's values to the Google ACS
7. Google's ACS verifies the SAML response using the partner's public key. If the response is successfully verified, ACS redirects the user to the destination URL.
8. The user has been redirected to the destination URL and is logged in to Google Apps.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I hope to read an anouncement like the fake one above by Google soon ;-)