Set up SSO (Single Sign-On)

In SSO-enabled domains without network masks, Google now requires super administrators to sign in with their Google username and password, and redirects users who aren't super administrators to the SSO sign-in page.

Google Apps offers a Single Sign-On (SSO) service to customers using Google Apps for Business, Education, or ISPs. SSO lets users access all of their Google Apps (including the Admin console) after signing in to an SSO sign-in page just once. Google redirects users to the SSO sign-in page when they try to sign in to the Admin console or another Google service.

Google provides a SAML-based SSO API that you can use to integrate into your LDAP, or other SSO system. LDAP (Lightweight Directory Access Protocol) is a networking protocol for querying and modifying directory services running over TCP/IP.

SSO accepts public keys and certificates generated with either the RSA or DSA algorithm. To use the service, you need to generate the set of public and private keys and an X.509 certificate that contains the public key. Once you have a public key or certificate, you would then need to register it with Google. You can do this by simply uploading the key or certificate via your Google Admin console.

How do I upload keys and certificates with my Google Admin console?

 

  1. Sign in to the Google Admin console
  2. Click Security > Advanced settings. Where is it? 
  3. Click Set up single sign-on (SSO).
  4. Enter the appropriate URLs and upload your verification certificate.

 

Visit the SSO Reference for more instructions.

How do I generate keys and certificates for the Google Apps Single Sign-On service?

The way you generate keys and certificates often depends on your development platform and programming language preference. You can use OpenSSL, Certificate Creation tool and Pvk2pfx tool in .NET, Keytool in Java, and Java Cryptography Architecture for creating public and private key pairs. More information

How does the verification certificate work?

The certificate file will be an X.509 formatted certificate with an embedded public key. The public key can use either the DSA or RSA algorithms. Google uses this key to verify the origination (i.e. Did the SSO assertion come from you?) and integrity (i.e. Was the assertion modified during transmission?) of the SAML response you send to us.

It is important to match the embedded public key in the X.509 certificate with the private key you use to sign the SAML Response.

While we don't currently support a best practice for admins without existing certificates, X509 certificates generation can be accomplished using the openssl command. More information

How does the 'Issuer' (i.e., the entity ID) element in the SAML request work?

The issuer is included in the SAML request to the IdP (Identity Provider). You can choose whether to included a standard or domain specific issuer. When multiple domains are using SSO with the same IdP aggregator, a specific issuer can be parsed by the IdP aggregator to identify the correct domain name for the SAML request. If you don't check the box to enable a domain specific issuer, Google will send the standard issuer (google.com) in the SAML request. If you check the box to enable this feature, Google will send an issuer specific to your domain (google.com/a/your_domain.com), where 'your_domain.com' is replaced with your actual domain name.

How do network masks work?

Network masks are IP addresses represented using Classless Inter-Domain Routing (CIDR) notation. The CIDR is a specification of how many bits of the IP address should be included. Google uses network masks to determine which IPs or ranges of IPs to present with the SSO feature.

It is important for each network mask to use the correct format. Here is an IPv6 example:

  • 2001:db8::/32 (where the slash and the number after it represent the CIDR)
In this example, the last 96 bits would not be taken into consideration, and all of the IPs in that network range would be affected.

Here is an IPv4 example:
  • 64.233.187.0/24
In this example, the last 8 bits (i.e. the zero) would not be taken into consideration, and all of the IPs that were in the range of 64.233.187.0 - 64.233.187.255 would be affected.

 

In domains with no network mask, add users who are not super administrators to the Identity Provider (IdP).

How does enabling SSO affect how users sign in?

The sign-in page for the Admin console is admin.google.com (which redirects to accounts.google.com), while the sign-in page for an individual Google service is <service>.google.com/a/<your_domain>.com. When you configure SSO for your domain, the behavior of these pages depends on whether the user signing in has super administrator privileges, and whether the domain has a network mask.

In SSO-enabled domains with a network mask:

  • When users (with or without super administrator privileges) try to sign in to accounts.google.com, Google prompts them for their full Google email address (including username and domain) and password, and takes them directly to the Admin console after they sign in. Google does not redirect them to the SSO server, regardless of the network mask.
  • When users (with or without super administrator privileges) within the network mask try to sign in to <service>.google.com/a/<your_domain>.com, Google redirects them to the SSO server.
  • When users (with or without super administrator privileges) outside of the network mask try to sign in to <service>.google.com/a/<your_domain>.com, Google does not redirect them to the SSO server.

 

In SSO-enabled domains without a network mask:

  • When super administrators try to sign in to accounts.google.com, Google prompts them for their full Google email address (including username and domain) and password, and takes them directly to the Admin console after they sign in. Google does not redirect them to the SSO server.
  • When users without super administrator privileges try to sign at accounts.google.com, Google redirects them to the SSO server./li>
  • When users without super administrator privileges, such as delegated administrators, try to sign in to admin.google.com, Google redirects them to the SSO server after they enter their Google username and click Sign in.
  • When users (with or without super administrator privileges) try to sign in to <service>.google.com/a/<your_domain>.com, Google redirects them to the SSO server.

 

How does SSO impact super administrators?

SSO only affects super administrators who try to sign in to a Google service at <service>.google.com/a/<your_domain>.com. SSO does not affect super administrators who try to sign in to an SSO-enabled domain via admin.google.com.

 

When super administrators log in on to the Drive sync client, they bypass the SSO.

When super administrators try to sign in to an SSO-enabled domain (with or without a network mask) via admin.google.com, they must enter their full Google administrator account email address and associated Google password (not their SSO username and password), and click Sign in to directly access the Admin console. Google does not redirect them to the SSO sign-in page. This applies to sign-in attempts from browsers, mobile apps (such as the iOS Drive and Gmail apps), the Android account activation flow, and so forth.

When super administrators try to sign in to another Google service at <service>.google.com/a/<your_domain>.com, Google redirects them to the SSO sign-in page only if they're signing in from within their domain's network mask. If they're outside of their domain's network mask, or if their domain doesn't have a network mask, Google prompts them for their Google username and password.

I have a question that is not covered above.

You can visit the Single Sign-On FAQs to find answers to common questions or read Single Sign-On articles. Alternatively, there are a number of commercial products and system integrators that provide SSO products and professional services. Please search the Professional Services in our Google Apps Marketplace for Google Enterprise Partners and other third parties that provide SSO assistance.

Read Troubleshooting Single Sign-On to resolve common issues encountered when integrating Google Apps with SSO.