Interop information for Google's SAML IDP

UPDATE: The interop testing with this feature was concluded in July 2009. It is no longer maintained. We suggest using Google's OpenID support instead.

We have a very simple SAML IDP whose purpose is to enable us to start interop testing and decide what the minimum features are that we need to support to be worthwhile. The IDP supports RP-initiated requests. Requests should be sent unsigned, using the Redirect binding. Responses are sent using the POST binding. We will serve a SAML metadata document that will describe the IDP and provide a self-signed key that can be used to verify assertions.

We currently have SAML enabled for only one test domain, lso-test-domain.com. There is test account in that domain with username "test" and password "8744G2". RPs that want to interop test

will need to send Dan Born (dborn@google.com) or Dirk Balfanz (balfanz@google.com) the EntityID that they would put in the <Issuer> in AuthnRequests and their ACS URLs so that they can be whitelisted. The metadata URL is (https://www.google.com/accounts/o8/saml/meta?hd=lso-test-domain.com). The IDP URL (given in the metadata document) is (https://www.google.com/a/lso-test-domain.com/o8/saml/idp?be=o8).

We expect AuthnRequests that look like:

<AuthnRequest IssueInstant="2009-06-30T23:25:33.000Z"

ID="A1246404333"

Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:protocol"

xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">

<saml:Issuer>YourEntityID</saml:Issuer>

</AuthnRequest>

If the EntityID in the AuthnRequest matches a whitelisted EntityID, then an assertion will be sent to the corresponding ACS URL. See the attached files for the type of requests expected and responses generated. YourEntityID is typically a metadata URL, but this is not required for now. Our longer term plan is to implement something very close to Dynamic SAML or Dynamic Federation (http://www.pingidentity.com/blogs/ctotalk/index.cfm/2007/11/27/Dynamic-Federation-Under-the-Covers) (http://www.computer.org/portal/site/security/menuitem.6f7b2414551cb84651286b108bcd45f3/index.jsp?&pName=security_level1_article&TheCat=1001&path=security/2008/n2&file=bsi.xml&).

We would require RPs to send signed requests and publish SAML metadata at a specific location. RPs would not have to be whitelisted with the IDP, but instead users would be prompted if they want to be redirected to a particular RP's site.

The responses from the IDP use a user ID number as the Subject, and include 1 SAML attribute named "email". The email address of a user can change, so we prefer the user ID as the primary identifier.

There are 2 different kinds of RPs we expect to be working with. The first kind would be an RP where the Google Apps admin sent them account provisioning data (ID, name, email, etc.) over some other channel (not SAML). This kind of RP just needs to receive the ID in the SAML assertion. The other kind of RP would be an unregistered/unknown RP that has no data about the user. We assume they would need a little more information, but we still wanted to keep it minimal, so we send an email Attribute.

.