The workflow of an access to Google Apps with authentication delegation corresponds to the web SSO profile in the SAML norm we discussed earlier. It involves eight steps, as shown in the following figure:
Enabling and adjusting settings of the authentication delegation is performed using the Advanced tools in the Google Apps console.
The first URL should point towards the SSO redirection page of Shibboleth (see below). It has the following form:
https://my-domain.com/idp/profile/SAML2/Redirect/SSO
For the time being, Shibboleth does not yet implement any logout procedure. The second URL should point towards a static page that asks the user to quit his browser.
The third URL should point to a page that allows users to change their password.
At the bottom of the page, a button allows the administrator to upload the certificate generated by Shibboleth to Google, which can use it in the ACS to check the authenticity of the responses.
The details of Shibboleth configuration are too complex to be discussed here. The most important task involves setting up various XML configuration files and metadata files for the IdP. Without going into detail, here is the list of files to be created or updated.
The a
im here is to configure Shibboleth so that the IdP "knows" that it is talking to a Google Apps domain using the HTTP protocol. The file is google-metadata.xml
.
This
is where the SAML profile that will be used is defined. This defines the workflow of the authentication process. The file name is relying-party.xml
.
Google expects to find the username in the SAML assertion returned by the IdP. It is necessary to properly configure Shibboleth for that. This is done in two XML files: namely, attribute-resolver.xml
and attribute-filter.xml
. When deploying to a production environment, it is likely that the Google Apps username won't be the same as the ID used with the IdP. In this case, the Google username should be stored in an LDAP directory or a database.
Google also provides a strong authentication mechanism that strengthens the security of data access. Recall that strong authentication implies supplying at least two proofs of identity. The usual password is obviously the first one. The other proof is a physically unique object that the user exhibits as a "proof of possession", just like a passport.
For Google Apps, this second proof of identity is a single-usage code that the user receives on his phone. This way, even a pirate who has stolen a password won't be able to access the account without owning the associated phone.
The disposable code provided by Google is fetched using a mobile app named Google Authenticator. Once the app has been installed on the smartphone, it is necessary to associate it with the user's account. Two methods are available. The first method is to scan a bar code that displays on the smartphone. The second is to enter, in the phone, a secret code that was generated on the user's Google account.
The generation of the single-use code by the Google Authenticator uses open standards from the Initiative for Open Authentication (OATH). The application runs on most smartphones: Google Android, RIM BlackBerry, and Apple iPhone iOS.
Strong authentication is only available in the "Premier", "Education", and "Government" editions of Google Apps. This feature should be activated by the Google Apps administrator. This strong authentication mechanism can be used by a single user on several Google accounts. This is usually termed multi-account access.