Achieving Single Sign-on with Google Apps and Shibboleth 2.0

Will Norris, University of Southern California
January 2008


Shibboleth is standards-based, open source middleware software which provides web single sign-on across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner.

Version 2.0 of the Shibboleth Identity Provider supports the SAML2 specification and is therefore ideal for use with Google Apps. This document will describe the steps required to configure a stock Shibboleth 2.0 Identity Provider to achieve single sign-on with Google Apps. It does not attempt to cover the steps required to install Shibboleth, for that please refer to the Shibboleth Wiki.

Configuring Google Apps

Setup SSO

First configure your Google Apps instance to look to Shibboleth for single sign-on. To do this, go to the Google Apps domain management screen, click on Advanced tools, and then on Set up single sign-on (SSO). Configure the following options:

Configuring Shibboleth

Add Google Metadata

The Shibboleth IdP must know some basic information about the Google relying party, which is defined in SAML metadata. The easiest way to do this is to create a new IDP_HOME/metadata/google-metadata.xml file with the following contents. There is much more information that could be added here, but this is the minimum required to get things working. Be sure to replace YOURDOMAIN.COM with the domain you have set up in Google Apps.

<EntityDescriptor entityID="" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
    <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
            Location="" />

Configure Relying Party

Instruct Shibboleth how to behave when talking to Google by defining a new RelyingParty element in IDP_HOME/conf/relying-party.xml. The following snippet should be added just after the DefaultRelyingParty element. Be sure to replace the provider attribute to include your entity ID (use whatever provider is configured in the DefaultRelyingParty).

<RelyingParty id=""
    <ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never" encryptNameIds="never" />

Still in the IDP_HOME/conf/relying-party.xml file, configure Shibboleth to use the new metadata file you created earlier. Add the following MetadataProvider element next to the existing configured provider (it should have an id value of “FSMD”), making sure to replace IDP_HOME with your actual installation path.

<!-- Google Metadata -->
<MetadataProvider id="GoogleMD" xsi:type="FilesystemMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"
    metadataFile="IDP_HOME/metadata/google-metadata.xml" maintainExpiredMetadata="true" />

Configure Attribute Resolver

Google expects the username of the user logging in to be passed as the SAML Name Identifier. Shibboleth’s attribute resolver must be configured to make this data available by modifying IDP_HOME/conf/attribute-resolver.xml. The following attribute definition provides a very basic method to do this by sending the principal name that was used to authenticate to the IdP. For production deployments where the name used to authenticate the user might not match the account name at Google, you may need to store the Google Apps ID in a relational database or LDAP directory.

<resolver:AttributeDefinition id="principal" xsi:type="PrincipalName" xmlns="urn:mace:shibboleth:2.0:resolver:ad">
    <resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
        nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />

Configure Attribute Filter

Finally, configure the Shibboleth attribute filtering engine to release the principal attribute (encoded as a NameID) to Google. Add the following XML snippet to IDP_HOME/conf/attribute-filter.xml alongside the existing policy elements.

    <PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="" />

    <AttributeRule attributeID="principal">
        <PermitValueRule xsi:type="basic:ANY" />


If all went well, you should now having Shibboleth 2.0 successfully authenticating users to Google Apps. With the possible exception of a more robust attribute resolver configuration (retrieving the Google ID from LDAP or a database) this configuration should be well-suited for large-scale production deployments.

Shibboleth has a very active user community that can be found contributing to the Shibboleth wiki or on the mailing lists below.