How to Configure Google Workspace Cloud Identity Inbound SAML SSO

The Reverse SSO Scenario

Typically, Google Workspace acts as the primary Identity Provider (IdP) for an organization. Employees log into Google, and then use Google to seamlessly authenticate into third-party applications like Slack or Salesforce (this is Outbound SSO).

However, many enterprise environments have the exact opposite requirement. A massive corporation might already use Microsoft Entra ID (Azure AD), Okta, or Ping Identity as their master, global directory. In this scenario, the corporation does not want employees managing a separate Google password. They want the employees to log into Okta, and then seamlessly pass through to their Gmail and Google Drive without a secondary login prompt. This architecture is called Inbound SAML SSO.

By configuring Google Workspace as the Service Provider (SP) and delegating the authentication authority to an external IdP, you centralize your security policies (like Duo MFA or Conditional Access) entirely on the third-party directory.

Step 1: Gathering the IdP Metadata

Before configuring Google, you must log into your master IdP (e.g., Okta or Entra ID) and generate the SAML metadata. You need three specific pieces of information:

1. Sign-in page URL: Where Google will redirect users to type their password.
2. Sign-out page URL: Where Google redirects users when they click “Sign out.”
3. X.509 Certificate: The cryptographic public key that Google will use to verify the digital signature of the SAML assertion sent by the IdP. Download this as a .cer or .pem file.

Step 2: Configuring Google Workspace as the SP

Now, you must instruct Google to stop asking for passwords and instead trust the external IdP.

1. Log into the Google Workspace Admin Console using Super Administrator credentials.
2. Navigate to Security > Authentication > SSO with third party IdP.
3. Click Add SSO profile.
4. Check the box for Set up SSO with third-party identity provider.
5. Enter the Sign-in page URL and Sign-out page URL you gathered in Step 1.
6. Under Verification certificate, upload the X.509 certificate file.

Step 3: Defining the Network Masks (Optional but Critical)

By default, if you enable SSO globally, it applies to every single user, everywhere. If the third-party IdP goes offline, your entire company is locked out of Google Workspace, including your IT administrators.

To prevent this, you should define a network mask so that SSO only applies to users inside the corporate office, or alternatively, use Organizational Units (OUs) to exclude Super Admins.

1. To exclude admins, navigate to the specific OU containing your Super Admins in the Admin Console.
2. Open their SSO settings and select None instead of the third-party profile, ensuring they can always log in natively with a Google password.

Step 4: Providing the Google SP Details to the IdP

Finally, you must complete the circle by giving the third-party IdP the routing information for Google.

Back in your IdP’s administrative console (e.g., Okta), you will need to input Google’s ACS (Assertion Consumer Service) URL and Entity ID.

• ACS URL: https://www.google.com/a/your-domain.com/acs
• Entity ID: google.com
• Name ID Format: Select EmailAddress. (This is crucial: The IdP must send the user’s primary email address in the SAML assertion so Google knows which inbox to open).

The Login Flow

The configuration is complete. Now, when an employee opens a browser and navigates to mail.google.com, they type their email address and press Enter. Google’s servers instantly recognize the domain is configured for Inbound SSO. Google refuses to show a password field; instead, it generates a SAML request and redirects the user’s browser to the Okta/Entra ID login page. Once authenticated there, the browser is bounced back to Google with a digitally signed token, and the Gmail inbox opens seamlessly.