Google Apps for Work Security Guidance: Single sign-on and remote access
Published 2 November 2015
© Crown copyright 2015
This publication is licensed under the terms of the Open Government Licence v3.0 except where otherwise stated. To view this licence, visit nationalarchives.gov.uk/doc/open-government-licence/version/3 or write to the Information Policy Team, The National Archives, Kew, London TW9 4DU, or email: psi@nationalarchives.gov.uk.
Where we have identified any third party copyright information you will need to obtain permission from the copyright holders concerned.
This publication is available at https://www.gov.uk/government/publications/google-apps-for-work-security-guidance/google-apps-for-work-security-guidance-single-sign-on-and-remote-access
This document gives deployment security considerations relating to Single Sign-On (SSO) configuration and Remote Access to the Google Apps for Work (GAFW) web service. The secure configuration of this cloud hosted service aligns with government’s guidance on implementing the Cloud Security Principles. Please send any feedback you may have to enquiries@cesg.gsi.gov.uk.
1. What is Single Sign-On?
A Google Apps user usually signs in using a Google Account. Their identity consists of a username and password managed by Google. SSO simplifies this process by allowing a user to log into GAFW using their existing enterprise username and password. The SSO logon may happen automatically, although this depends on how the enterprise and its devices are configured.
2. Google and SSO
Google Apps for Work supports two ways of implementing a single-authorisation mechanism:
- Directory Synchronisation - a server component copies enterprise accounts to Google’s cloud, including a copy of the password hash
- SSO - the browser receives a security token from the enterprise and uses it to identify the user to GAFW
In SSO, third party Identity Providers (IdPs) are used to hold users’ username and password credentials which authorise and authenticate them to Google’s web applications. One common way of implementing this is to use an existing on-premise deployment of Active Directory Federation Services (ADFS) as the IdP.
CESG recommend mechanisms that use identity federation rather than account synchronisation. However, if SSO is implemented, Google-provided authentication mechanisms (such as two-factor authentication) will no longer be available. CESG recommend that when choosing an SSO provider, the authentication measures offered are considered.
Once SSO is set up, the login experience will be determined by the IdP. The user may be prompted to type in their enterprise username and password, or they may be automatically logged in using Kerberos authentication or a client-side certificate. The IdP product choice and configuration will determine how seamless this experience is to the user.
Google can federate with identity services that implement SAML 2.0 identity federation. Federation ensures that there is no requirement to store enterprise passwords in the cloud.
Certificates should be put in place to ensure a trust relationship that will allow Google to trust an enterprise’s authentication assertions. The Google SSO service requires an administrator to generate a set of public and private keys and an X.509 certificate containing the public key. The certificate is then registered with Google via the Google Admin Console so that GAFW can validate identity assertions. Google document a number of different ways of generating keys and how they can be registered.
3. SSO compatibility
Google Apps for Work supports SSO when accessed through a number of official tools. This includes Google’s web applications as well as some official Google mobile apps. Synchronisation tools to improve integration with traditional desktop computers such as Google Drive and Google Apps Sync also support SSO.
Some enterprises rely on legacy protocols supported by GAFW that do not work with SSO, such as accessing Gmail over POP/IMAP. If these features are still required, users will need to be provided with Google passwords; either unique ones, or existing passwords synchronised with a local LDAP server. The additional risks associated with using a legacy mechanism will need to be understood and accepted by the risk owner.
4. Web access
Public cloud services such as GAFW are designed to be accessed from any device with an internet connection. Some enterprises prefer to only allow their information to be accessed from authorised devices, whether these are enterprise managed or personal devices that meet a required security specification. These two approaches therefore appear to conflict.
There is no easy way to audit web access to GAFW since no administrator accessible log is available to show which devices GAFW users have logged in from. If you wish to restrict access to enterprise data to a subset of devices, one solution is to implement procedural controls for End User Devices (EUDs) which allow users to only log into GAFW from certain devices. CESG have produced some guidance on securely configuring EUDs.
5. Restricting access to known devices
There is no specific control in GAFW designed to restrict access to the service by network location or device through mechanisms such as IP range boundaries or the forcing of user certificate-based authentication. However, it is possible to restrict access to GAFW to only known devices by configuring SSO so only devices connected to the enterprise network can authenticate:
With SSO configured as shown above, EUDs can only log in to GAFW when they can see the IdP. This ensures that only devices connected directly to the enterprise network and those approved to connect using a Virtual Private Network (VPN) will be able to log in to GAFW.
SSO can also be configured to work with online IdPs. All enterprise-approved EUDs should be provisioned with a non-exportable client certificate that identifies the user as a member of the enterprise. This certificate should be hardware-backed on supported devices. The IdP is required to only accept authentication from devices that have this certificate. The logon could also identify the unique user using the certificate, streamlining logon.
6. Shared devices
Google sets non-persistent session cookies once a user has successfully logged in, whether or not SSO is being used. If a chosen SSO implementation provides persistent session management, CESG recommend that users should be advised to manually log out of GAFW. This will ensure that the cookie is deleted and in doing so separate user sessions on shared devices. It cannot be assumed that Google will delete the SSO cookie set by the IdP.
7. Mobile Device Management
GAFW Mobile Device Management allows an administrator to control mobile device access to their GAFW instance. Settings are configured via the GAC and policies pushed to EUDs to enforce governance over how that device can access GAFW. For example, it is possible to:
- control which EUDs can access GAFW data
- configure mobile settings by organisational unit
8. References
In addition to the web pages referenced in the list of URLs below, Google provide documentation to support SSO deployments including an FAQ and a troubleshooting guide:
Successfully deploying a GAFW Mobile Device Management instance requires careful planning and testing. Google provide clear documentation to support an Mobile Device Management rollout. In particular, a comprehensive reference is available:
See also CESG’s documentation on End User Devices Security and Configuration Guidance.