TrustedX for Managing Access to Google Apps
More and more public and private sector companies are migrating their mail and collaboration applications to Google Apps, a service offered by Google that makes the more common office applications available in the cloud. For these organizations, it is vital that their data stored in the cloud is well protected, for which they require strong authentication mechanisms that they can even manage themselves.
Google Apps is a suite of mail and collaboration Web applications that is made available as Software as a Service (SaaS). This software model means client organizations do not need to install any additional software or storage hardware. They only need to carry out minimal administration procedures, which equates to a significant cost saving. To access the applications Google Apps provides a user management service, but it also provides tools for configuring other identity providers.
For organizations that want to manage end-user authentication processes themselves, Google Apps provides the Single Sign-On service, which uses the SAML (Security Assertion Markup Language) federation standard for integrating third-party credential validation servers. The scenario is as follows: applications are stored in Google's public cloud, users can connect to these applications from public or corporate networks, and in both cases, user authentication is carried out by Google Apps client organization.
Thus, the client organization can use the passwords stored in its LDAP directories or opt for other strong authentication mechanisms, such as digital certificates, one-time passwords generated by hardware or software tokens, biometric credentials, etc. So, the Google Apps client organization can act as an identity provider or even delegate this function to another entity.
Safelayer has carried out a concept test of this scenario using TrustedX as identity provider and its QR-Scan OTP experimental application as a strong authentication mechanism. In order to do so, the Google Single Sign-On service must be enabled in the Google Apps administration panel and the identity provider data must be configured, which is mainly the access URL and the server authentication certificate.
The process is straightforward and is triggered when a user tries to access one of the corporate applications in Google Apps (1). Google Single Sign-On service generates a SAML authentication request and redirects it to the configured identity provider (2). The identity provider, composed by TrustedX and an external authentication agent, interprets the authentication request and initiates the user's authentication process with the QR-Scan OTP mechanism (3, 4, 5). The identity provider validates the user's credentials and links the authentication to an identity stored in the LDAP directory service (6, 7). After validation, the identity provider builds a SAML response and sends it back to Google Apps (8) via the user's browser.
In this concept test, the use of QR-Scan OTP authentication mechanism provides greater guarantees than the static password as it uses a strong multi-factor mechanism that involves the use of public key technologies. However, the federation schema provided by TrustedX, as identity provider, is versatile and can support several other mechanisms.
