Table of Contents
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
- My first Google Workspace tenant = ci.goldyarora.com
- Test user in this Google Workspace tenant is email@example.com
Service Provider Domain
- My second Google Workspace tenant = sandbox.goldyarora.com
- Test user in this Google Workspace tenant is firstname.lastname@example.org
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.
- 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.
We would have a custom attribute in our Google Workspace Identity provider (e.g Google-to-Google-SSO-Email)
Custom Attribute as nameId
Our SSO configuration would send this custom attribute (Google-to-Google-SSO-Email) as nameId in SAML response.
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 email@example.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 firstname.lastname@example.org TO email@example.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 firstname.lastname@example.org has a custom attribute called Google-to-Google-SSO-Email which has the value email@example.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.
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 firstname.lastname@example.org 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 email@example.com in my case)
Google Workspace to Google Workspace SSO Setup
Login to admin console of Google Workspace (IDP) and go to users.
Click on “Manage custom attributes” from the more men dropdown as shown in the screenshot below.
Create a new custom attribute which we would be using as nameId in our SAML response to another Google Workspace instance (SP).
- Name your custom attribute category (e.g Google to Google SSO).
- Write some contextual description to your custom attribute category.
- 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.
- You may look at below screenshot for reference.
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.
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 firstname.lastname@example.org.
You would now see that the custom attribute is populated on this user’s profile.
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.
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.
As this group would be used for application assignment only, I would make it custom and keep the controls with myself.
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
Click on + icon to add a new SAML application.
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.
- Take a note of SSO URL as we’ll need it later.
- Click to download the certificate.
- 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.
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.
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.
- 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.
Setup SSO in Google Workspace Service Provider
- Login to the Google Workspace Admin console (service provider side), and click on Security.
- Click on “Setup SSO with a third party IdP.
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.
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.
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.
You should now be logged in to your another Google Workspace tenant to the account you configured in custom attribute.
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).
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 email@example.com in my case).
Enter your password here (for Google Workspace IDP domain email address).
You should be logged in to the account of another Google Workspace (service provider) tenant (e.g sandbox.goldyarora.com in my case).
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.
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 firstname.lastname@example.org)
- 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.