Table of Contents
G Suite to G Suite SSO Overview
Topic Overview & Expected Output
- There might be use cases where you would like to setup federation between two G Suite or Google Cloud Identity tenants so users in one of your Google account can login to another one via their existing G Suite or Google Cloud Identity accounts.
A use case that I have seen is-:
- You are an enterprise customer and have received free G Suite 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.
G Suite 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 G Suite or Google Cloud Identity tenant as identity provider and another one as service provider.
My scenario for this setup-:
Identity Provider Domain
- My first G Suite tenant = ci.goldyarora.com
- Test user in this G Suite tenant is email@example.com
Service Provider Domain
- My second G Suite tenant = sandbox.goldyarora.com
- Test user in this G Suite 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 G Suite or Google Cloud Identity account, they should be redirected to their ci.goldyarora.com G Suite (or Google Cloud Identity) login page, and then back to sandbox.goldyarora.com’s account after successful login.
- If my users go to their G Suite dashboard in ci.goldyarora.com, they should see an application icon to login to another G Suite 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), G Suite (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 G Suite tenants only if you have such case and really want to do it via SAML, otherwise you may consider G Suite Password Vaulted Apps (if you are on G Suite 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 G Suite 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 G Suite service provider tenant will receive its user's primary email id in nameId for successful login.
Understanding Federation between two G Suite tenants
As a service provider G Suite 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 G Suite IdP tenant (e.g ci.goldyarora.com) to our G Suite 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 G Suite 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 G Suite IdP tenant (e.g Google-to-Google-SSO-Email) and then populate this custom attribute with our users’ email that they have in our G Suite 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 G Suite 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 G Suite (or Google Cloud Identity) tenants.
G Suite to G Suite SSO : System Requirements
Identity Provider G Suite (or Google Cloud Identity) tenant requirements :
- Verified Domain (e.g ci.goldyarora.com in my case)
- G Suite or Google Cloud Identity Super Administrator role
- At least one test user (e.g firstname.lastname@example.org in my case)
Service Provider G Suite (or Google Cloud Identity) tenant requirements :
- Verified Domain (e.g sandbox.goldyarora.com in my case)
- G Suite or Google Cloud Identity account with at least Security settings privilege
- At least one test user (e.g email@example.com in my case)
G Suite to G Suite SSO Setup
Login to admin console of G Suite (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 G Suite 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 G Suite tenant.
For e.g I want this user to be able to login to another G Suite 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 G Suite saml app later, go to your G Suite 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 G Suite 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 G Suite IdP.
1. Login to G Suite 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 G Suite 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 G Suite (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 G Suite instance.
2. In entity id, enter google.com/a/yourdomain.com where yourdomain.com should be replaced by your actual domain in service provider G Suite 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 G Suite 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 G Suite 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 G Suite Service Provider
- Login to the G Suite 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 G Suite IdP side.
2. Enter https://accounts.google.com/logout in the sign our page url.
3. Upload the certificate you downloaded earlier from your G Suite (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 G Suite service provider account.
You should now be logged in to your another G Suite 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 G Suite service provider).
It should redirect you to another G Suite instance (IDP) where you would need to put primary email address of your G Suite IDP domain (e.g email@example.com in my case).
Enter your password here (for G Suite IDP domain email address).
You should be logged in to the account of another G Suite (service provider) tenant (e.g sandbox.goldyarora.com in my case).
Here am listing some of the frequently asked questions about G Suite to G Suite 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 G Suite to G Suite SSO.
No, G Suite (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 G Suite 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 G Suite and Google Cloud Identity customers without any additional cost.
Google Cloud Identity (or G Suite) 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.