This guide outlines the configuration of a Google SAML Application to accept authentication requests from an AAF Rapid IdP instance. In this mode of operation, the Rapid IdP service provides access to federation enabled services and proxies all user authentication requests to an organisation's Google Authentication Service. The following steps are a subset of those required to complete the configuration of a Rapid IdP instance, either as a new service or as a prerequisite to migrating an existing identity provider to the AAF’s Rapid IdP Service.


The AAF will provide the necessary details to complete the configuration of the Google Application. The AAF will need to receive the Google IdP metadata to complete the configuration of the Rapid IdP service.

This guide is one in a series for connecting and proxying cloud based authentication to AAF's Rapid IdP Service. These guides will eventually cover Google, Okta, Azure and Ping Identity.

In proxying authentication requests to a third-party authentication service like Google, Rapid IdP no longer requires access to an organisation's on premise LDAP service for authentication or to source user attribute values. However, the necessary user attribute values must be available within the third-party authentication service for Rapid IdP to retrieve and release user attributes to those federation connected services to which users authenticate.

Google’s authentication service does not currently support encryption of user’s information within a SAML response. This is not entirely an issue, since all of the user’s data is already sent over an encrypted transport. However, this means that there is nowhere to add the encryption certificate provided by the AAF within Google’s Admin tool. Therefore, if the AAF provides a signing certificate, it can be ignored.

Step 1 - Sign in to the Google Admin dashboard

Access the Google Workspace Admin dashboard.

Step 2 - Select Apps / Web and mobile apps

Navigate to the Web and Mobile Apps configuration page.

Step 3 - Select Add App then Add custom SAML app

Select the Add Custom SAML App menu item.

Step 4 - Give the App a name

Clear labelling of the application is important if the same Google Workspace will connect to both the AAF Rapid IdP Test service and the AAF Rapid IdP Production service.

Use Option 1 on this page to download the Google IdP’s metadata. Option 2 can be ignored since the metadata will already contain the SSO URL and the Entity ID values. The metadata for the Google IdP must be sent to the AAF to be included in the Rapid IdP configuration. 

Step 6 - Add the Service Provider details

The AAF will provide the necessary details to complete this section before you begin configuring the Google Application. From the AAF provided information:

  • Add the Audience URI [1] (or Entity ID) value into the Entity ID field.
  • Add the Single Sign On URL [2] value into the ACS URL field.
  • All other details can be left blank or their default values.

[1]    Also known as Audience Restriction or Service Provider Entity ID
[2]    a) Also known as ACS (Assertion Consumer Service)
       b) Use this same value for Recipient URL and Destination URL

Step 7 - Add attribute mappings

Attribute names are case-sensitive, administrators need to ensure that App Attribute labels match the AAF attribute names exactly. These mappings can be created before values have been added to user accounts.

Complete documentation on AAF Attributes is available here:

AAF Core Attributes are the standard vocabulary for the federation and the higher education and research sector. Subscribers may find it useful to explore these attributes to gain a better understanding of their purpose. Organisations are only required to support those attributes in the core list. Subscribers should select mappings that closely align Google Attributes with the AAF attributes definitions. 

The following attributes are consumed without modification from an organisation’s Google Workspace:

  • mail
  • givenName
  • surname
  • displayName (may be available or can be generated by the Rapid IdP service by combining 
  • givenName and surname).
  • eduPersonAffiliation (can also be defined statically within Rapid IdP if all users have the same type of affiliation with an organisation).

The following attributes are typically generated by the Rapid IdP service from a single persistent, non-reassignable, unique identifier provided by an organisation:

  • auEduPersonSharedToken
  • eduPersonTargetedID
  • persistentNameID

Sources of persistent, non-reassignable, unique (for an organisation) identifiers commonly include: employeeID, studentID, unix uidnumber or other identity management system internal identifier that is sticky to the individual throughout their entire identity lifecycle with an organisation, including when an individual returns to an organisation after any period of time. 

When there is no suitable attribute, the AAF will make recommendations for generating a suitable identifier for users. Values, for this identifier, will need to be imported into the Google Workspace for every user. The process of adding values for this attribute should become part of an organisation's account creation procedure and documented accordingly.

As an interim measure until the process is automated, Google offers the following guidance for managing users in a workspace without scripting, see the heading "Update many profiles from a spreadsheet"

This Google support document provides guidance for creating custom attributes:

The following attributes are generated by the Rapid IdP service based on the available values for other identifiers mapped to the Google App attributes:

  • eduPersonPrincipalName (combining uid or a suitable immutable persistent identifier and scope)

  • eduPersonScopedAffiliation (combining eduPersonAffiliation and homeOrganization)

The following attributes are generated (or are defined statically) by the Rapid IdP service at the time of user authentication:

  • authenticationMethod

  • eduPersonAssurance

  • eduPersonEntitlement

  • homeOrganization

  • homeOrganizationType

  • o (aka: organizationName)

  • scope

Step 8 - Enable for all users

It may take up to 24 hours for the Google service to complete the configuration and be available for all users. Generally, it should only take a few minutes.

Step 9 - Testing

Testing is a little difficult even though a TEST SAML LOGIN option is available. Testing ideally requires a service to receive the login token. Once the AAF has received the Google IdP metadata and configured the Rapid IdP instance, testing can occur against the AAF’s Validator Service at for the AAF's Test Federation or for the AAF's Production Federation. These services will display all the released attributes for an individual.


These instructions were derived from the following Google Support document

AAF Test Validator

AAF Production Validator