Google Workspace to Google Workspace SSO

Table of Contents

1. Topic Overview

Overview of our scenario and expected output .

Jump to section

2. SSO Architecture

Our architecture for federation between two Google Workspace tenants.

Jump to section

3. System Requirements

Let us ensure system prerequisite for Google Workspace to Google Workspace SSO.

Jump to section

4. Google Workspace to Google Workspace SSO Setup

Step by step instructions to setup Google Workspace to Google Workspace SSO.

Jump to section

5. FAQs

Get answer to FAQs, or ask if you have any question.

Jump to section

Google Workspace to Google Workspace SSO Overview

Topic Overview & Expected Output

  • There might be use cases where you would like to setup federation between two Google Workspace or Google Cloud Identity tenants so users in one of your Google account can login to another one via their existing Google Workspace or Google Cloud Identity accounts.

A use case that I have seen is-:

  • You are an enterprise customer and have received free Google Workspace sandbox tenant from Google to perform testing for new features before rolling them out in production, and you do not want to manage separate credentials for production and sandbox domain, rather you want to login to sandbox via your production account.

Google Workspace or Google Cloud Identity is very flexible and it can be used as “Service Provider”, Identity provider or even both.

In this blog post, I will show you how you can have one Google Workspace or Google Cloud Identity tenant as identity provider and another one as service provider.

My scenario for this setup-:

Identity Provider Domain

  1. My first Google Workspace tenant = ci.goldyarora.com
  2. Test user in this Google Workspace tenant is admin@ci.goldyarora.com

Service Provider Domain

  1. My second Google Workspace tenant = sandbox.goldyarora.com
  2. Test user in this Google Workspace tenant is demo@sandbox.goldyarora.com

What should I see after the federation setup?

My users in ci.goldyarora.com (IDP) should be able to sign in to their sandbox.goldyarora.com (SP) accounts without a need to remember their sandbox.goldyarora.com credentials (via SAML 2.0).

  • If my users directly go to sandbox.goldyarora.com (SP) to login to their Google Workspace or Google Cloud Identity account, they should be redirected to their ci.goldyarora.com Google Workspace (or Google Cloud Identity) login page, and then back to sandbox.goldyarora.com’s account after successful login.

  • If my users go to their Google Workspace dashboard in ci.goldyarora.com, they should see an application icon to login to another Google Workspace account, once they click on it, they should be logged in to their sandbox.goldyarora.com account.

 Important Notes:

  • By the time of writing this post (July 2020), Google Workspace (or Google Cloud Identity) does not support partial SSO, which means once you turn on SSO, “ALL” your users would be redirected to configured Identity provider.

  • You should attempt SAML 2.0 based federation between two Google Workspace tenants only if you have such case and really want to do it via SAML, otherwise you may consider Google Workspace Password Vaulted Apps (if you are on Google Workspace Enterprise or Cloud Identity Premium plan) or any other password manager (e.g chrome password manager, lastpass etc), it won’t be true SSO, but users would not to remember another set of credentials.

Undestanding Federation Architecture

In this section, let’s understand how our two Google tenants would be able to federate seamlessly.

Google Workspace as IdP

Custom Attribute

We would have a custom attribute in our Google Workspace Identity provider (e.g Google-to-Google-SSO-Email)

Google Workspace as IdP

Custom Attribute as nameId

Our SSO configuration would send this custom attribute (Google-to-Google-SSO-Email) as nameId in SAML response.

Google Workspace as SP

Seamless Login

Our Google Workspace service provider tenant will receive its user's primary email id in nameId for successful login.

Understanding Federation between two Google Workspace tenants

As a service provider Google Workspace or Google Cloud Identity accepts its users’ primary email address in nameID in the SAML response.

This means, when we send SAML response from our Google Workspace IdP tenant (e.g ci.goldyarora.com) to our Google Workspace SP tenant (e.g sandbox.goldyarora.com), it should contain SP tenant’s user’s primary email address (e.g demo@sandbox.goldyarora.com).

However, Google does not support attribute transformation on the fly (e.g we can not write an attribute transformation rule saying when users try to access sandbox.goldyarora.com Google Workspace tenant, convert their email from user@ci.goldyarora.com TO user@sandbox.goldyarora.com while sending the SAML response).

Custom Attribute as a workaround :

As a workaround, we would create a custom attribute in our Google Workspace IdP tenant (e.g Google-to-Google-SSO-Email) and then populate this custom attribute with our users’ email that they have in our Google Workspace SP tenant.

So, now our sample user admin@ci.goldyarora.com has a custom attribute called Google-to-Google-SSO-Email which has the value demo@sandbox.goldyarora.com).

We will now ask Google to rather send this custom attribute in nameId when sending SAML response to our service provider Google Workspace tenant.

You may leverage Google’s directory API to populate custom attribute value in bulk, I might add an apps script soon in this blog post which would help managing this custom attribute right from a Google sheet automatically. 

System Requirements

Lets look at the system requirements which you should complete for seamless federation between two Google Workspace (or Google Cloud Identity) tenants.

Google Workspace to Google Workspace SSO : System Requirements

Identity Provider Google Workspace (or Google Cloud Identity) tenant requirements :

  • Verified Domain (e.g ci.goldyarora.com in my case)
  • Google Workspace or Google Cloud Identity Super Administrator role
  • At least one test user (e.g admin@ci.goldyarora.com in my case)

Service Provider Google Workspace (or Google Cloud Identity) tenant requirements :

  • Verified Domain (e.g sandbox.goldyarora.com in my case)
  • Google Workspace or Google Cloud Identity account with at least Security settings privilege
  • At least one test user (e.g demo@sandbox.goldyarora.com in my case)

Google Workspace to Google Workspace SSO Setup

Login to admin console of Google Workspace (IDP) and go to users.

1. Go to Google Workspace Users in Admin console

Click on “Manage custom attributes” from the more men dropdown as shown in the screenshot below.

2. Click on Manage custom attributes in g suite admin console

Create a new custom attribute which we would be using as nameId in our SAML response to another Google Workspace instance (SP).

  1. Name your custom attribute category (e.g Google to Google SSO).
  2. Write some contextual description to your custom attribute category.
  3. Create custom field (e.g google-to-google-sso), make it a Text data type, and assign visibility as you need (e.g visible to admin or user or to all), make it single value.
  4. You may look at below screenshot for reference.
3. add a custom attribute

Now, let us add the value in our custom attribute for our test user.

Click on pencil icon to add custom attribute value as shown in the screenshot below.

13. add custom attribute value

Enter this user’s respective email address in another Google Workspace tenant.

For e.g I want this user to be able to login to another Google Workspace tenant in the mailbox of demo@sandbox.goldyarora.com.

14. add g suite sp user email in custom field

You would now see that the custom attribute is populated on this user’s profile.

15. you would see custom field value for your g suite user now

Now, we will create a dedicated Group to which we’ll assign our Google Workspace saml app later, go to your Google Workspace Admin console (IDP one) and click on groups.

30. Go to Google Workspace Groups

Create a new group and add member/s as required, for now I would add just myself to it, as I would prefer testing it before adding more members to it.

Our idea is that anyone who is part of this group would have access to our Google Workspace service provider tenant.

16. create a new g suite group

As this group would be used for application assignment only, I would make it custom and keep the controls with myself.

17. keep google group custom

Setup custom SAML app in Google Workspace IdP.

1. Login to Google Workspace or Google Cloud Identity Admin Console (Identity provider tenant)

2. Go to Apps, and then click on SAML apps as shown in the screenshot below 

Go to SAML Apps in Google Admin Console

Click on + icon to add a new SAML application.

Click plus icon to add a new SAML app

As Google Workspace or Google Cloud Identity application is not part of the provided catalogue, we’ll click on “setup my own custom app” as shown below.

4. create a new saml app
  1. Take a note of SSO URL as we’ll need it later.
  2. Click to download the certificate.
5. note down your saml app details
  • You can enter some details about your new SAML application to give context to your users.
  • E.g enter your Google Workspace (service provider tenant) name, description, and add a logo.
6. enter your saml app details

You would need to enter service provider details here (look at the screenshot below for reference).

1. Enter your ACS url (it should be https://www.google.com/a/yourdomain.com/acs) where yourdomain.com should be replaced by your actual domain name in service provider Google Workspace instance.

2. In entity id, enter google.com/a/yourdomain.com where yourdomain.com should be replaced by your actual domain in service provider Google Workspace instance. 

3. You can enter the URL of the application where your users should land at when they authenticate (via IDP) (e.g mail.google.com, drive.google.com etc), I want my users to rather go to Google Workspace dashboard, so i would enter https://gsuite.google.com/dashboard

4. Click on signed response so our whole SAML response should be signed.

5. Important – for nameId, choose the custom attribute you created (and populated) earlier.

6. Keep Name Id format unspecified.

7. Finally, save changes.

10. enter your g suite sp details in idp

We do not need to add any attribute mapping here, as Google just needs user’s primary email address in the SAML response.

Click on Finish to complete the setup.

11. finish google saml app setup
  • Assign our new Google Workspace application to the group we created earlier, we have only put one member in our group for now, so we can test it out, and once everything works fine, we can add more members to the group.
20. assign saml app access to your group

Setup SSO in Google Workspace Service Provider

  • Login to the Google Workspace Admin console (service provider side), and click on Security.
7. go to security in g suite admin console
  • Click on “Setup SSO with a third party IdP.
8. go to sso with third party

Enter the values as shown below (look at the screenshot below for reference).

1. Enter the SSO URL you copied earlier from your Google Workspace IdP side.

2. Enter https://accounts.google.com/logout  in the sign our page url.

3. Upload the certificate you downloaded earlier from your Google Workspace (IdP).

4. Click on “Use a domain specific issuer”.

5. I don’t think Google provides a straight password change Url, so I will just enter https://accounts.google.com.

6. Enable SSO by checking the box on “Setup SSO with third party identity provider”.

7. Save changes.

12. setup g suite sso

Now go to gsuite.google.com/dashboard,  this new application would appear on the user dashboard (if this user is part of the group we created and assigned to this application).

Click on this application to start our testing.

21. you would now see the saml app in g suite dashboard

Google might ask you to verify that you are trying to login via SAML (This is a security measure in place to avoid someone tricking you to get you click on a button and get access via SAML behind the scene).

Click on continue to login to your Google Workspace service provider account.

26. click on continue to your g suite account

You should now be logged in to your another Google Workspace tenant to the account you configured in custom attribute.

22. user is logged in to another g suite instance

Now let us test service provider (SP) initiated sign on too, go to any of your assigned applications like drive.google.com, and enter your email address (one you have in Google Workspace service provider).

23. g suite sp initiated sso

It should redirect you to another Google Workspace instance (IDP) where you would need to put primary email address of your Google Workspace IDP domain (e.g admin@ci.goldyarora.com in my case).

24. enter your g suite idp email

Enter your password here (for Google Workspace IDP domain email address).

25. enter your g suite idp user password

You should be logged in to the account of another Google Workspace (service provider) tenant (e.g sandbox.goldyarora.com in my case).

22. user is logged in to another g suite instance

FAQs

Here am listing some of the frequently asked questions about Google Workspace to Google Workspace SSO, please comment in the bottom if you have any question, and I will add it (along with the answer) to FAQs.

FAQ

Most frequent questions and answers about Google Workspace to Google Workspace SSO.

No, Google Workspace (or Google Cloud Identity) does not provide automated user provisioning option to another Google tenant.

So it wouldn’t be possible this way, however you may consider other options for bulk provisioning like my google sheet add-on Ok Goldy

Only Google Workspace or Google Cloud Identity Super Administrators can add SAML applications.

Please make sure you are assigned Super Admin role.

No, Google does not support 3rd party MFA integration.

However you should be able to leverage Google’s MFA (which supports multiple MFA methods including FIDO keys).

Google’s MFA is available to Google Workspace and Google Cloud Identity customers without any additional cost.

Google Cloud Identity (or Google Workspace) Administrators with Reporting privilege can look at SAML logs.

Following SAML Login logs are available at this path Admin Console –> Reports –> Audit –> SAML

SAML Login Logs :

  • Event Name – (e.g Successful login)
  • Event description (e.g Goldy Arora logged in)
  • User (e.g admin@id.goldyarora.com)
  • Application Name (e.g Microsoft Office 365)
  • Organization name (user’s orgUnit name like /Contractors)
  • Initiated by (who initiated the login e.g Service provider or Identity Provider)
  • Failure type (if any failure, e.g Application not configured)
  • Response status (e.g SUCCESS_URI)
  • Response second level status
  • IP Address (login user’s IP address, e.g 96.248.xxx.xx)
  • Date (date and time of user login, e.g 3 Feb 2020, 08:47:59 GMT-5) 

Ask it in the comments below, and I would try to answer it (if i can) as soon as I get time.

RECOMMENDED READING

As you just read Google Workspace to Google Workspace SSO – Setup federation between two Google tenants, I would recommend following as complimentary reading.
Google Workspace to Office 365 SSO & Provisioning Guide
AdminGoogle WorkspaceSecuritySSO

Google Workspace to Office 365 SSO and Provisioning Guide

Read More →
Okta - Google - Integration - Guide
AdminGoogle WorkspaceSecuritySSO

Definitive Guide to Okta & Google Integration

Read More →
Password-Vaulted-Apps-Service-in-Google Workspace-and-Google-Cloud-Identity
AdminGoogle WorkspaceSecuritySSO

Securely login to any app with Google Workspace Password Vaulted Apps

Read More →

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top