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:
- A user wants to access Google Apps.
- Google generates a SAML authentication request. Things happen seamlessly for the user. The request contains the name of the application the user wants to access.
- The browser redirects the request to the IdP service.
- The IdP decodes the authentication request and extracts the parameters encapsulated in the SAML request. The IdP authenticates the user either by asking him or her to enter his credentials or by validating session cookies.
- The IdP generates a SAML assertion that contains the account ID for that user. The request is signed with the private key of the IdP.
- The IdP sends the signed SAML response to the Google's ACS (Assertion Consumer Service) by means of a browser redirection.
- The ACS checks the genuineness of the response using the certificate (public key) from the IdP.
- Lastly, the user's browser is redirected to the Google Apps service whose name was stored in the URL for the duration of the process.
The authentication steps for accessing a Google Apps domain when authentication delegation is used
Enabling and adjusting settings of the authentication delegation is performed using the Advanced tools in the Google Apps console.
Configuring authentication delegation 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.
Google Authenticator applications on mobile
Entering the disposable code in the Google interface
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.