You can configure your Cloud Identity or Google Workspace account to usesingle sign-on (SSO). When you enable SSO, users aren't prompted to enter apassword when they try to access Google services. Instead, they are redirectedto anexternal identity provider (IdP) to authenticate.

Using SSO can provide several advantages:

• You enable a better experience for users because they can use theirexisting credentials to authenticate and don't have to enter credentials asoften.
• You ensure that your existing IdP remains the system of record forauthenticating users.
• You don't have to synchronize passwords to Cloud Identity orGoogle Workspace.

To use SSO, a user must have a user account in Cloud Identity or Google Workspace and acorresponding identity in the external IdP. SSO is therefore commonly used in combination with anexternal authoritative source that automatically provisions users to Cloud Identity or Google Workspace.

Single sign-on process

Cloud Identity and Google Workspace support Security Assertion MarkupLanguage (SAML) 2.0 for single sign-on. SAML is an open standard for exchangingauthentication and authorization data between a SAML IdP and SAML serviceproviders. When you use SSO for Cloud Identity or Google Workspace, yourexternal IdP is the SAML IdP and Google is the SAML service provider.

Google implementsSAML 2.0 HTTP POST binding.This binding specifies how authentication information is exchanged between theSAML IdP and SAML service provider. The following diagram illustrates an exampleof how this process works when you use SSO to access the Google Cloud console.

1. You point your browser to the Google Cloud console (or any otherGoogle resource that requires authentication).
2. Because you are not yet authenticated, the Google Cloud consoleredirects your browser to Google Sign-In.
3. Google Sign-In returns a Sign-In page, prompting you to enter your emailaddress.
4. You enter your email address and submit the form.
5. Google Sign-In looks up the Cloud Identity or Google Workspaceaccount that is associated with your email address.

6. Because the associated Cloud Identity or Google Workspaceaccount has single sign-on enabled, Google Sign-In redirects the browser tothe URL of the configured external IdP. Before issuing the redirect, itadds two parameters to the URL,RelayState andSAMLRequest.

   • RelayState contains an identifier that the external IdP is expectedto pass back later.

   • SAMLRequest contains theSAML authentication request, an XMLdocument that has beendeflated,base64-encoded, and URL-encoded. In decoded form, the SAML authenticationrequest looks similar to the following:

     <samlp:AuthnRequestProviderName="google.com"IsPassive="false"AssertionConsumerServiceURL="https://www.google.com/a/example.com/acs"...><saml:Issuerxmlns:saml="...">google.com</saml:Issuer><samlp:NameIDPolicyAllowCreate="true"Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/></samlp:AuthnRequest>

   This example request instructs the external IdP to authenticate theuser, create a SAML assertion for the audiencegoogle.com, and post it tothe assertion consumer service (ACS) athttps://www.google.com/a/example.com/acs.

   The domain that is embedded in the ACS URL (example.com) correspondsto the primary domain of your Google Workspace orCloud Identity account.

   If you use the domain-specific issuer feature when you configure SSO, theissuer isgoogle.com/a/DOMAIN instead ofgoogle.com, whereDOMAIN is the primary domain ofyour Cloud Identity or Google Workspace account.

   The steps taken by the external IdP to perform the authentication dependon the IdP and its configuration—for example, it might display a logindialog, or it might prompt for MFA or a fingerprint. When these steps havebeen completed successfully, the SAML exchange continues:

   

7. The external IdP returns a specially crafted HTML page that causes yourbrowser to immediately send an HTTP POST request to the ACS URL. Thisrequest contains two parameters:

   • RelayState, which contains the value originally passed to the IdP inthe SAML authentication request.

   • SAMLResponse, which contains the base64-encodedSAML assertion. TheSAML assertion is an XML document that states that the IdP hassuccessfully authenticated the user. In decoded form, the SAML assertionlooks similar to the following:

     <samlp:Response...>...<Assertionx...><Issuer>https://idp.example.org/</Issuer><Signature...>...</Signature><Subject><NameIDFormat="...:nameid-format:emailAddress">bob@example.org</NameID>...</Subject><ConditionsNotBefore="..."NotOnOrAfter="..."><AudienceRestriction><Audience>google.com</Audience></AudienceRestriction></Conditions><AttributeStatement>...</AttributeStatement><AuthnStatementAuthnInstant="..."...><AuthnContext><AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef></AuthnContext></AuthnStatement></Assertion></samlp:Response>

   This example assertion has been issued for the audiencegoogle.com(matching the issuer of the SAML authentication request) and states thatthe IdPhttps://idp.example.org/ has authenticated the userbob@example.org.

   The SAML assertion also contains a digital signature. The IdP creates thissignature by using the private key of a signing certificate. The privatekey is known only to the IdP. The corresponding public key is part of theSSO configuration in Cloud Identity or Google Workspace andshared with Google Sign-In.

   The SAML assertion also contains a digital signature that enables the SAMLservice provider to verify the assertion's authenticity.

8. The browser posts the SAML assertion to the Google ACS endpoint.

9. The ACS endpoint verifies the digital signature of the SAML assertion.This check is done to ensure that the assertion originates from the trustedexternal IdP and has not been tampered with. Assuming the signature isvalid, the ACS endpoint then analyzes the contents of the assertion,which includes verifying its audience information and reading theNameID attribute.

10. The ACS endpoint looks up your user account by matching theNameID ofthe SAML assertion to the primary email address of the user. Theendpoint then starts a session.

11. Based on the information encoded in theRelayState parameter, theendpoint determines the URL of the resource that you originally intendedto access, and you are redirected to the Google Cloud console.

IdP-initiated Sign-in

The process outlined in the previous section is sometimes referred to asservice provider–initiated sign-on because the process starts at the serviceprovider, which in the preceding example is the Google Cloud console.

SAML also defines an alternative flow calledIdP-initiated sign-on, whichstarts at the IdP. Google does not support this flow, but you canachieve similar results by using the following URL to initiate an serviceprovider–initiated sign-on:

https://www.google.com/a/DOMAIN/ServiceLogin?continue=https://console.cloud.google.com/

In this example,DOMAIN is the primary domainof your Cloud Identity or Google Workspace account.

Multi-factor authentication

To protect user accounts from unauthorized access, you can require users toprovide a second factor during authentication. There are two ways to implementmulti-factor authentication when using single sign-on:

1. If your external IdP supports multi-factor authentication, you can haveit perform the multi-factor authentication as part of the SAML-basedsign-on process. No additional configuration is required inCloud Identity or Google Workspace in this case.
2. If your IdP does not support multi-factor authentication, you canconfigure your Cloud Identity or Google Workspace account toperform two-step verification immediately after a user has authenticated with the external IdP.

Networking

In SAML 2.0 HTTP Redirect binding, the IdP and service provider don'tcommunicate directly. Instead, all communication is relayed through the user'sbrowser, as shown in the following diagram:

Given this architecture, it is not necessary for the IdP to be exposed over theinternet, or to even have internet access, as long as users are able to accessit from your corporate network.

Configuration of the external IdP

Cloud Identity and Google Workspace let you configure singlesign-on by using the following features:

• SAML profiles: You can create a SAML profile for each IdP that you want tointegrate with. For each user, group, or organizational unit in yourCloud Identity or Google Workspace account, you thendecide whether they must use SSO, and which SAML profile theymust use.

• Legacy SAML profile (formerly namedorganizational SSO profile):You can use the legacy SAML profile to integrate with a single IdP.For each user, group, or organizationalunit in your Cloud Identity or Google Workspace account, you thendecide whether they must use SSO or not.

The right way to configure your IdP depends on whether you use SAML profilesor the legacy SAML profile. The following table summarizes the settingsthat typically have to be configured in an external IdP to help ensurecompatibility.

• Review thereference architectures for integrating with an external IdP.
• Learn how to set up account provisioning and SSO withMicrosoft Entra ID orActive Directory.
• Read ourBest practices for federating Google Cloud with an external IdP.

Contributors

Author:Johannes Passing | Cloud Solutions Architect