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 article is specific to connecting to the Google Authentication Service, as a discrete task during one of the following activities:

  • deployment of a new Rapid IdP instance
  • migrating an existing identity provider to the Rapid IdP service
  • converting an existing Rapid IdP service from LDAP authentication to a cloud based authentication service.


These activities follow a similar pattern and are outlined in the article On-premise IdP Migration to Rapid IdP.


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 and AzureAD.


The AAF will provide the necessary details to start the configuration of the Google IdP Service. The AAF will need to receive the Google IdP metadata certificate and settings to complete the configuration of the Rapid IdP service. 


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.


If there is no configuration item to input the AAF provided signing certificate within the Google Administrative Dashboard, it can be safely ignored. This means user information is not encrypted within the SAML response, but the user’s data is sent over an encrypted transport session.


Before starting configuration of the Google SAML Application, the AAF will provide the following information to complete the configuration:

  • an Audience URI - which exactly matches the Shibboleth IdP EntityID if migrating an existing service
  • the Single Sign On URL - also known as ACS (Assertion Consumer Service). Use this value for Recipient URL and Destination URL if necessary
  • a list of SAML attribute names that Rapid IdP is expecting - attribute names are case-sensitive
  • a certificate for signing assertions - if the Google Dashboard allows the import of an external certificate.


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 AAF Production and Test Federations. For Test Federation AAF Rapid IdP-Test is sufficient. For Production Federation AAF Rapid IdP-Prod is suitable. End users will not see this name since all requests to the login service will be by Service Provider initiated logins. End users will not see this name since all requests to the login service will be by Service Provider initiated logins. 

Click the Continue button.



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. 


Google IdP’s metadata includes a signing certificate for signing tokens issued to Rapid Idp.


It should be noted that the max age on the default certificate is typically two years. Administrators should note the expiry date to replace this certificate. Alternatively, consider creating and uploading a new certificate with a longer expiry period (beyond the scope of this article) to replace the default certificate before downloading and providing the Federation Metadata XML file to the AAF.


 


Step 5 - Add the Service Provider details

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 6 - 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: https://validator.aaf.edu.au/documentation.

AAF Core Attributes are the standard vocabulary for the federation and the higher education and research sector.


To assist with mapping Google values to AAF attributes, explore the AAF attribute definitions to gain an understanding of their purpose and usage. The selection of Okta attributes should be such that they align closely to the AAF attribute descriptions. Organisations are only required to support the attributes in the core list.


The following attributes are consumed without modification:

  • mail

  • givenName

  • surname

  • displayName - this can be a direct mapping or Rapid IdP can generate the value by combining firstName and Surname values

  • eduPersonAffiliation - can be defined statically by Rapid IdP if all users have the same affiliation status within an organisation

  • eduPersonEntitlement - if not available, may be defined statically within Rapid IdP.


The following attributes are 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 away. 

When there is no suitable attribute, the AAF will make recommendations, on a case-by-case basis in consultation with an organisation, for deploying an immutable identifier for every user. Unique values, for this identifier, will need to be available 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" https://support.google.com/a/answer/6191788?hl=en

This Google support document provides guidance for creating custom attributes:
https://support.google.com/a/answer/6208725?hl=en


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 (combines uid or a suitable immutable persistent identifier and homeOrganization)

  • eduPersonScopedAffiliation (combines eduPersonAffiliation and homeOrganization)


The following attributes are generated by the Rapid IdP service at the time of user authentication:

  • authenticationMethod

  • eduPersonAssurance


The following attributes are defined statically:

  • homeOrganization (the organisation's security domain, ie: example.edu.au) 
  • homeOrganizationType
  • ‘O’ - aka: organizationName.

Step 7 - 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 8 - Testing

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 https://validator.test.aaf.edu.au for the AAF's Test Federation or https://validator.aaf.edu.au for the AAF's Production Federation. These services will display all the released attributes for an individual.


Links

These instructions were derived from the following Google Support document

https://support.google.com/a/answer/6087519?hl=en&ref_topic=7559288

AAF Test Validator https://validator.test.aaf.edu.au/

AAF Production Validator https://validator.aaf.edu.au/