DEFINITIVE GUIDE TO OKTA & GOOGLE INTEGRATION

  • I used to work with Okta, and I must say, amazing people, great product, and very ūüí™ūüí™ fit management:)

  • I also got an opportunity to implement Okta and G Suite for some enterprises in my IT consulting career, some went pretty smooth, and some had a few learning lessons.

  • I thought to share my experience via this detailed blog post to help community seamlessly integrate Okta with Google (G Suite and/or Google Cloud Platform)

Table of Contents

1. SSO & Provisioning Overview

Cetranlized user lifecycle and SSO - Overview & Benefits

Jump to section

2. SSO Terminology

SSO and provisioning terminology in plain enlsigh.

Jump to section

3. User Provisioning via Okta

Instructions to setup Google user provisioning via Okta

Jump to section

4. SSO to Google via Okta

Step by step instructions to setup Okta SSO for Google

Jump to section

5. Advance Use Cases

Attribute transformation, existing Google Users

Jump to section

6. GCDS vs Okta Provisioning

Which one should you use? Rationale & Recommendation

Jump to section

7. FAQs

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

Jump to section

1. SSO & Provisioning Overview

This section includes SSO overview, how does SSO help in providing rich user experience along with increasing our security posture.

SSO & User Lifecycle Management with Okta

Before I show you how to set up Google SSO and user lifecycle management with Okta, let us first understand why we need it in the first place. I mean what are we missing in life if we do not even have Okta or its integration with Google.

For that, let me take a scenario, lets say your company uses 10 different software applications to perform day to day tasks, for e.g Salesforce for CRM, G Suite for messaging and collaboration, Asana for task management etc.

Now, when a new employee joins you, your IT Administrator would go and create this new employee’s account in these 10 different applications (one by one), and then finally send the user id and password of each of these apps to the user.

Manually creating user accounts in 10 different applications, yuck…. That is painful…..very time consuming, but let me add some flavor to it.

What if you are a big business, and 100 new employees join you today?

Oh.. and what if 100 leave you every month, would you not need to then go to those 10 applications and delete these accounts????

and what if by any chance your IT Administrator (being human) missed to delete a user’s account from any of these applications? security compromised……..

It is not just your IT administrator who gets all the frustration here, it is also shared by your regular employees, because they now need to manage 10 different user ids and passwords (one for each application).

Now, if you are in this situation, what would you do? May be keep the same user id and password for all those applications, which works well as you only need to remember one set of credentials, but if your password gets compromised, that means all your 10 apps are potentially compromised because you have same password for them too.

So, to summarize, here are the problems-:

Administration Problems

  • Time consuming and de-centralized user management

  • Lack of security (what if an Admin forgets to remove a user account from an application after the user leaves your company)

User Problems

  • Multiple user ids and passwords to manage

  • Lack of productivity, less than ideal experience

  • Lack of security (if user changes password of each app and make it same)

Now, let us see how using a centralized Identity and Access management solution can help us with these problems, though this post is about Okta / Google integration, however conceptually it does not matter which Identity and Access management solution you use (e.g ADFS, Ping Identity, Google Cloud Identity, AzureAD etc).

Administration Benefits with Okta-:

  • Okta sync very well with your Active Directory or LDAP to bring all your existing identities (e.g users, groups) into Okta.

  • Now, you do not need to create users accounts manually in to target applications (like G Suite, Salesforce etc), as Okta connects with them very well leveraging their APIs.

  • Once you integrate Okta with these target applications, you only need to provision your users once, either in your Active Directory or in Okta, and then Okta will provision (and de-provision) this user automatically in those 10 applications in our case.

  • Okta Administrator can apply policies such as enforce Multi Factor Authentication when a user is trying to login to a critical application, or may if a user is trying to login from outside the office.

User benefits with Okta-:

  • Rich User experience -: Users do not need to remember multiple user ids and passwords for different apps, they only need to login to Okta, and they will be presented with application icons, just click on those icons to login to those applications‚Ķ‚Ķ yeah‚Ķ‚Ķ..

  • Secure Access based on the access policies setup by Okta Admi

2. SSO & Provisioning Terminology

In this section, let us understand frequently used terminology in Provisioning and SSO including ones which are specific to Okta and Google.

Simplified SSO & User Lifecycle terminology

I hate talking about technical jargon, but it is important to understand some of the terms which will be used frequently, though I am not an expert by any means but i’ll try my best to help you understand these jargons in simple terms.

Identity Provider (IdP) -:

    • Identity Provider or IdP for short is an authority system which provides the identity of the user to the relying parties.

       

    • Take an example of DMV which verifies your 6 points id and then issues you a driving license, now you can present this licenses as your identity to other places like at Airport security.

    • In this example, Airport security is a service provider which is relying on DMV as the identity provider.

Service Provider (SP)-:

    • Service Provider (SP) is also called Relying Party (RP) in Single Sign On world. It is usually an application or service which relies on the Identity provider to authenticate the user and provide its service to him/her.

    • In our example above, Airport Service is a service provider (or relying party) and DMV is an Identity provider (IdP).

Let us understand them better with one more example РThis weekend I went to a bar near me to have couple of IPAs:), they asked me for a proof which shows me as 21 years or older, I presented my driving license, here DMV is my identity provider and this bar is the relying party (or Service provider) as it is relying on DMV to provide me the service (beer as a service…. yeah….).

Security Assertion Markup Language (SAML)-:

    • When two entities talk to each other, they need to agree to talk in a predetermined language, right? Let say if the president of the United States of America is talking to the Prime Minister of India about negotiating a deal, how would they understand each other as they speak different languages?

       

    • Ideally, they would have a translator who understands both languages and then help these leaders with the translation in their own language, so they can make informed decisions.

       

    • Similarly, when Okta and Google need to talk to each other where Okta will say to Google ‚ÄėHey Google, I confirm, Goldy is our employee, let him login to G Suite‚Äô, this interaction takes place in the language or standard they both understand, this language is called ‚ÄúSecurity Assertion Markup Language‚ÄĚ or SAML for short.

       

    • As per Wikipedia -: Security Assertion Markup Language (SAML, pronounced SAM-el) is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.
       

User Attributes-:

    • Attributes are like properties of a user, which helps us gain more information about a user, for example, if a user‚Äôs job title is CEO, that tells that this user is¬† an executive, or if the user‚Äôs department = sales, that tells us that this user works in the sales department.

       

    • There can be multiple attributes assigned to a user (like first name, last name, email, phone, department, employee ID etc).

       

    • You might also create custom attributes which are so specific to your business, for example if your company provides uniform to employees,¬† you might want to know the shirt size of your employees, and would create an attribute like shirt_Size which will then be filled up based on respective user‚Äôs shirt size like S, M, L, XL etc.

       

    • These attributes help us make dynamic rules as we will see later in the post, for e.g create a rule in Okta which says if the user.status = ‘full time employee’, then assign G Suite application to these users.

Attribute Transformation-:

    • Sometime you would see scenarios where you would need to change the attribute‚Äôs value on the fly, let me give you an example, our domain name is @olddomain.com in Okta, but in G Suite our domain name is @newdomain.com.

       

    • Now, Google expects that Okta will refer to user@newdomain.com in all the interactions as Google does not have any information about user@olddomain.com.

       

    • In this specific case, we can create an attribute transformation rule in Okta saying, if the user is trying to access G Suite, change their email address on the fly from user@olddomain.com TO user@newdomain.com, this is called ‚ÄėAttribute Transformation‚Äô, geeky way of saying this would be ‚ÄėSend transformed attribute in the SAML response‚Äô.

       

    • This way, Okta can send the user attribute value which is expected by the target application without changing this user‚Äôs attribute in Okta or for other applications assigned to this user in Okta.

Single Sign On (SSO)-:

    • An authentication method where a user can login to multiple applications with just one set of credentials is called Single Sign On (SSO).

       

    • This one set of credentials belong to user‚Äôs identity provider (for e.g Okta in our use case here), and then behind the scenes this identity provider integrates with other applications or service providers (e.g G Suite, Salesforce etc).

      These applications rely on Identity provider for user authentication instead of asking users to provide user id and password.

       

RelayState
    • You can think of the relayState as the first destination where you will land after your IdP authenticates you to the service provider.

    • For example, after Okta authenticates you to Google, whether you would land at Gmail, or Google Drive or Google Sites, it really depends on what you have set up in the relayState parameter of the SAML response.

    • This might be helpful to know, especially for cases where you want your users to land at a specific Google service after authenticating themselves via Okta.
 

Network Masking-:

    • This is specific to Google Cloud Identity (or G Suite) where you can restrict the scope of Single Sign On (SSO) to an IP range.

       

    • For example, if you put an IP range in Google‚Äôs network mask while setting up SSO, Google will only redirect users to your IdP if they login from an IP address that belongs to this IP range, other users will be required to login via their Google email address and password as usual.

Classless inter-domain routing (CIDR)-:

    • When you configure Networking Mask in Google while setting up SSO, it does not take the IP addresses, rather a CIDR.

       

    • CIDR is a flexible way to define how many bits of an IP address belong to the network (network ID) vs host (e.g host ID), so if you take C class IP4 (192.168.12.12) as an example here and put /32 to it (e.g¬†192.168.12.12/32), then it means 32 bits (note /32) are the network id which will result in just one IP address.

       

    • We will use this when setting up Okta SSO with G Suite, so we can restrict SSO scope to only one IP address for testing before enabling it to all users in our company.

Session Timeout-:

    • When you start interacting with an application, it would ask you to authenticate for the first time, however to provide you rich experience, it will create a session which will uniquely identify you, this helps avoid a situation where it needs to ask you to authenticate every time you do interaction with that application.

       

    • You would find different applications with their own default session timeout, for e.g G Suite (Gmail, Drive etc) has a default session timeout length of 14 days, which means once you authenticate yourself, then you would not need to authenticate for 14 days (except some scenarios like IP, location, reset cookies etc changes or Google finds something suspicious).

       

    • Some applications provide a way to change default session timeout and have your own custom setting there (like G Suite), which means if you change the default session timeout to 2 hours, then users will need to re-authenticate themselves every 2 hours.
SLO
    • Single Logout (SLO) -: When your Identity provider (e.g Okta) authenticates you to the service provider (e.g G Suite), a session is created. Now if you logout from Okta, your session is still active with G Suite, and if you logout from G Suite, your session is still active with Okta.

    • Single Logout (SLO) is a way to kill all the active sessions for both (Identity provider and Service provider).
 

User Provisioning to Google via OKta

In this section, let us understand how we can leverage Okta to manage our Google users lifecycle including creating, updating and suspending users.

Okta - Google - User Provisioning Guide
Play Video

Watch this video for step by step instructions

Perquisites

To get started, let us first understand what would we need to setup provisioning-:

  1. G Suite or Google Cloud Identity Super Administrator Email and Password.

     

  2. Okta Super Administrator User Id and Password

  3. Atleast one test user account in Okta (either created directly in Okta or brought over by Active Directory)

  4. You should have already taken care of Google Conflicting Accounts.

I would also recommend to have clarity on which users (and groups) you want to provision from Okta to Google before you start.

Though it really depends on your use case, but I have seen some use cases while doing Okta and G Suite implementations where enterprises provision based on following-:

  • AD Group based provisioning -: Some organizations create a group in their Active Directory called google_users and then use this as provisioning basis (e.g whoever is member of this group, provision them to Google).

  • AD OrgUnit based provisioning -: Though not usual but some organizations go with OrgUnit based approach where any user of a given AD orgUnit gets provisioned to Google (via Okta).

  • Attribute based approach -: Some organization in some complex or custom use cases also go with user attribute based provisioning (e.g if the user.department = “IT”, then provision them to Google.

Ideally unless you are very clear on your use case and provisioning approach, you should go with Group based provisioning as it provides more flexibility and do less strain on your AD.

I will show you group based provisioning as it is very commonly leveraged, however i’ll put details below on how to do orgUnit and user attribute based provisioning just in case if you need that.

Also, provisioning process is same regardless of whether you are using G Suite or Google Cloud Platform or Google Drive Enterprise.

 

Provisioning Steps

Login to your Okta tenant

  • Go to your Okta tenant (e.g yourcompany.okta.com)
  • Enter your User Id and Password (and second factor if it is setup)¬†
Login to Okta

Click on the Admin button on the to right to go to Okta Admin console (as shown in the screenshot below).

Go to Okta Admin
  • Go to Applications (as we will be adding G Suite application).
Go to Applications in Okta
  • Click on Add Application
Click on Add Application in Okta
  • Search for “G Suite” and click on it from the integrations as shown in the screenshot below.

Add G Suite Application for provisioning

  • Along with G Suite, products like Google Cloud Platform and Google Drive Enterprise also leverages Google Directory.

  • So even if you use Google Cloud Platform (without G Suite), you would still need to add G Suite app in Okta for provisioning to Google Directory.

  • Think of it like this, though the app here says G Suite, but you would be provisioning to Google Directory via it, which can then be used by products like G Suite, Google Cloud Platform or Google Drive for Enterprise.
Search and Select G Suite App in Okta
  • As you see in the screenshot below, this application supports user lifecycle management to Google Directory.

  • Click on Add button to add the G Suite application.
Click to Add G Suite app in Okta
  1.  Add your Application label (e.g G Suite), this can be changed later.

  2. Add your G Suite (or Google Cloud Identity) domain, this can NOT be changed later, please make sure to put it right.

  3. Okta provides users a single dashboard where users see the icons of the applications which are assigned to us, if you would provide Okta SSO access to access to G Suite, then check the apps you want to show on users dashboard.

    If you would only be using Google Cloud Platform (and not G Suite), then you would not want to show these icons (e.g Gmail, Drive etc) on your users Okta dashboard, hence these can be unchecked here.
Enter your G Suite domain in Okta
  • ¬†If you use G Suite, Okta provides you functionality to add licenses to your G Suite users. You may enter your G Suite license count here to leverage Okta seats related reporting.

  • You can decide whether to show G Suite application icons to users on their Okta dashbaord and in Okta’s mobile app.

  • You would rather be using SAML, do not worry about “Browser plugin auto-submit” and leave it unchecked.
Enter G Suite apps visibility in Okta
  1.  Click on SAML
  2. Click on Save
Note -: We are not turning on SAML or SSO yet, Okta only shows the user provisioning features once you enable SAML, hence we will just click on SAML and Save to move forward.
Select SAML and and click done in okta
  1.  Now you would see additional options in your G Suite app (make sure you are in the G Suite app that you started configuring)
  2. Click on “Provisioning” tab
  3. Click on “Configure API Integration”
FYI –: As Okta leverages Google’s Directory API to manage Google user lifecycle (e.g creating, deleting, updating Google users).
Go to Provisioning tab in Okta G Suite app
  1.  Click on Enable API Integration
  2. Then click on “Authentication with G Suite”
FYI –: We are now starting the process to authorize Okta (via OAuth) to programmatically (via Google’s Directory API) interact with our Google tenant for users, groups and members management.
Enable Google API Integration in Okta
  • Login to your G Suite Admin account (which should have either Super Admin OR delegated administration based on your requirements (e.g if you need Okta to manage only users, then delegated admin account here should have user management permissions)

  • If you are already logged in, please click on the account that you want to use to authorize Okta.
Give Okta permission to Google
  • Google is now providing you information about what Okta would be authorize to manage once you click allow.

  • You can also click on exclamation icons to learn more about each OAuth scope here.

  • Once/if satisfy, click Allow as shown in the screenshot below.
Provide Okta access to create users in G Suite
  • You should now see the successful message that your API integration has been enabled successfully.
Confirm success message in Okta
  • Click on Save.
Save you changes in Google app in Okta
  1.  Please make sure that you are in the same G Suite application that you are configuring

  2. Click on Provisioning

  3. Important –: Please make sure the flow of provisioning is from Okta to G Suite, and then click on “Edit” as shown in the screenshot below.
Select the Google app for provisioning
Edit Google provisioning in Okta
  1. Enable “Create Users” if you want Okta to create users in Google Directory.

  2. Enable “Update User Attributes” if you want your users attributes to be synchronized from Okta to Google.

  3. Enable “Deactivate Users” if you want your suspended or deleted Okta users can be suspended or deleted in Google.

  4. Enable “Sync Password” if you want Okta to push your Okta user password (or AD password if you have AD delegated authentication setup).

  5. Once done, click on Save to save your changes.
Enable Google user management in Okta
  • If you scroll below, you would see user attribute mapping, where Okta should have already mapped primary attributes (e.g Name, email etc).

  • However, Okta provides you flexibility to map any attributes as per your requirement including the custom attributes that you have created in your Okta (e.g a custom attribute called “T-Shirt Size” to sync with Google Directory.
map google and okta attributes

Testing our configuration

  • We are now done with setting up user provisioning from Okta to Google Directory, its time to test our configuration.

  • You would create a test user in your Okta tenant (or use existing if you already have one) and assign him/her G Suite application.
Note -: For now we first need to test our configuration with a test user, however later in this post we will set up group based provisioning for dynamic and scalable provisioning.
Add G Suite ass to test user
  • ¬†If you have configured integration with multiple G Suite tenants, please make sure to assign our test user the correct G Suite tenant.
Assign G Suite app to test user
  • ¬†Choose the Google Organization Unit where you want to create this test user.
Assign G Suite license to your test user
  1. ¬†By default Okta suspends the users who is deactivated in Okta, you can check the box “do not suspend user”, ideally leave it unchecked.

  2. Okta can provide your G Suite license reporting, you may consider putting “true” to manage licenses on create and update.

  3. Select the license you want Okta to apply to this user (Note – If you do not use G Suite, and configuring provisioning for GCP, you can select “Cloud Identity” license at the bottom from this list.

  4. Click on Save and go back.
Assign G Suite license if required
  • You should see the application as “Assigned” now, click on Done.
G Suite assignment is completed
  • You should give it a few minutes and then go to your Google Admin Console –> Reports –> Admin.

  • You should see that Okta created our test user account in Google and also assigned the license we requested for this user.
If it has been a few minutes and you still do not your test user created, please look at the logs in Okta and in Google. Also, please make sure your Google service account has required permissions.
User should be created in Google via Okta
Scaling our user provisioning
 
  • After testing our provisioning setup successfully, I will now leverage Okta’s “Group based provisioning” to add all required users to Google directory.

  • Okta supports (i) AD Mastered Groups (ii) Application Mastered Groups and (iii) Okta Mastered Groups for provisioning.

  • Though I personally prefer to go with Okta mastered groups because it allows to define dynamics membership rules (even if/else conditional rules), but let me show you both AD mastered and Okta mastered group assignment below.

  • Click on the toggle below to see configuration for AD mastered group and Okta mastered group.

If you already have a group in your Active Directory that includes the users you want to provision to Google (via Okta), then you can simply choose this group.

However, you would need to keep managing this group in Active Directory as Okta would be making changes to Google directory based on this group membership (e.g if someone is removed from this group, Okta would suspend that user from Google)

I personally prefer “Okta Managed” groups which allows more granularity as you see in the toggled section (Option 2) below.

Leveraging Okta mastered groups for provisioning in target app

I personally prefer to go with Okta groups because it allows to define dynamics memberships based rules (even conditional rules).

Let me show you how to create an Okta group, populate it with members based on our condition, and finally use it as a basis for provisioning.

Step 1-: Login to Okta Admin Console and go to Groups as shown below

Go to Groups in Okta

Step 2 – Click on “Add Group” to create a new Okta mastered group

Click on Add Group in Okta

Step 3 – Name your Group and give it a description to it becomes easy to find later

Create a new group in Okta

Step 4 – Create a new Rule

Let us now create a new rule in our Okta group to 

Create rule for group membership in Okta

Step 4 – Create a new Rule

  • You can add users to your Okta group either by selecting “Groups Memberships” as we are doing in the screenshot below.¬†

  • You can also use user attributes like user.department = “IT”

  • If you need more flexibility to go granular, you can leverage Okta expressions where you can really combine attributes and groups memberships, and can also use conditionals.

    In this example, I am simply asking Okta to add members of my Active Directory G Suite users to my G Suite Okta group (this will be dynamic so if i change the group membership in AD, it’ll be in sync at next Okta directory sync run).
Ad group in Okta
  • In this example below, I am using Okta’s expression language to only add members to my Okta G Suite group when they are members of G Suite group in my Active directory AND if their department is equal to IT.
Okta group based on expression
Go to G Suite app assignment tab in Okta

Assign Group for G Suite provisioning Scope

  • As our group is now available in Okta (either the AD mastered or Okta mastered group).

  • Its time to assign it to G Suite for our provisioning scope as shown in the screenshot below.
Select and assign your AD group to provision Google users via okta

SSO to Google via Okta

In this section, we will setup Okta as our Identity provider to Google, so our users can login to G Suite (or Google Cloud Platform) from Okta.

Okta-GSuite-SSO-Guide
Play Video

Watch this video if you use G Suite OR G Suite + Google Cloud Platform

Okta - Google Cloud Platform SSO
Play Video

Watch this video if you use Google Cloud Platform, but not G Suite

Perquisites for SSO to Google via Okta

To get started, let us first understand what would we need to setup SSO-:

  1. G Suite or Google Cloud Identity Super Administrator Email and Password.

     

  2. Okta Super Administrator User Id and Password

  3. Atleast one test user account in Okta (either created directly in Okta or brought over by Active Directory) who has also been provisioned in Google.

  4. Optional, but highly recommended – An IP address to test SSO before rolling it out in production.

Login to your Okta Administration Console.

Go to Okta Admin

Go to Applications as shown in the screenshot below.

Go to Applications in Okta
  • Click on the Sign On tab and then Click “SAML” radio button as shown in the screenshot below.
  • Now instructions would appear, click on “View Setup Instructions”.
go to G Suite app saml settings in okta

Scroll down a bit and copy the following as we will need them later when we configure SSO settings in G Suite.

  1.  Sign in page URL
  2. Sign out page URL
  3. Change Password URL
  4. Click on verification certificate to download it
Copy Okta Urls to put in G Suite SSO
  • Your certificate from Okta should be downloaded now, we’ll need this certificate later to upload in G Suite (or Google Cloud Identity) SSO settings.
Download the certificate from Okta for Google
  • ¬†Login to your G Suite (or Google Cloud Identity) Administration Console

  • Go to Security
Go to security from your Google Admin console
  • ¬†Scroll down to find “Setup Single Sign-On (SSO) with a third party IdP.

  • Click on it to open its settings.
Click to start G Suite SSO setup
  • ¬†Paste the SSO URL that you copied from Okta.

  • Paste the Sign out Url that you copied from Okta (your may put any url here where you want users to go when they sign out).
enter the SSO url you copied from Okta
  1.  Click on upload the certificate.
  2. Select the certificate that you downloaded from Okta.
  3. Upload it.
Upload the cert you copied from Okta to Google SSO
  1.  Please ensure your certificate has been uploaded as you see in the screenshot below.

  2. Check on “Use a domain specific issuer”.

  3. Put your testing IP address here in the CIDR format (You should put /32 to make the SSO only apply on this specific IP address.
    You can read more about Network mask feature in G Suite above.

  4. Paste the change password URL that you copied from Okta.

  5. Save your changes.
G Suite SSO Network mask
  1.  Though you would have your own specific settings from Okta, but they would something like shown in the screenshot.

    Now activate SSO by checking the box “Setup SSO with third party identity providers”
  2. Save your changes.

    As soon as we save our changes, SSO should be applied but ONLY from the test IP address we have put, all other authentication requests from other IP addresses should route through Google as usual.
Save your G Suite SSO settings
  • ¬†Now let us try to sign in via Okta (Idp Initiated sign on) to see how is our SSO working.

  • ¬†Please make sure of following-:

     

    • ¬†You are testing SSO via a test user (not the admin user, as Google admin users bypass SSO).

    • You are testing it from the IP address that you have put in Network mask above in Google SSO settings.
Try siging via Okta dashboard

We should be able to successfully login to G Suite now.

If you see any error, please ensure you have followed the above documentation well, or look at the FAQs section at the bottom of this post to understand common SSO errors and their solution.

Success signing to Gmail via IdP initiated
  • ¬†Now let us try to sign in via Google (Service Provider Initiated sign on) to see how is our SSO working.

  • ¬†Please make sure of following-:

    • ¬†You are testing SSO via a test user (not the admin user, as Google admin users bypass SSO).

    • You are testing it from the IP address that you have put in Network mask above in Google SSO settings.
try signing via G Suite
  • ¬†You should ideally be now redirected to your Okta Sign in page (unless you are not already signed into Okta).

  • Enter your Okta credentials to sign in.
Redirection to Okta SSO page
  • We should be able to successfully login to G Suite now.

    If you see any error, please ensure you have followed the above documentation well, or look at the FAQs section at the bottom of this post to understand common SSO errors and their solution.

Success signing to Gmail via IdP initiated

Handing Advance Scenarios

In this section, let us talk about handling some advance SSO scenarios like transforming attributes on the fly using Okta’s expression language etc.

Table of Contents for Advance Cases:

Different Domains in AD/Okta vs Google

Watch the video below if you have different domain in AD/Okta vs Google, but still want to do Okta SSO to Google.

Okta - Google - SSO - Different Domains
Play Video

I have done couple of Okta and G Suite implementation where due to rebranding those enterprises wanted to go with a new/rebranded company domain for G Suite.

Though it is not limited just to rebranding cases, think of acquisition cases where you acquire a company who is already using G Suite, but not Okta, you may merge them with you AD, but they would have different G Suite domain than of your Active Directory.

I have also seen some cases where enterprises intentionally go for a test domain when doing G Suite or Google Cloud Platform proof of concept.

Concerns-:

  • G Suite only accepts user’s primary email address as identifier to authenticate users via Identity providers like Okta.

  • However, in rebranding, POC or other similar cases, your users LDAP / Okta email would be different than G Suite, which means Okta will send user@oldDomain.com in the SAML but Google would need user@newDomain.com.

  • Hence the SAML SSO will not work.

Solution-:

  • We can leverage Okta’s attribute transformation feature which provide flexibility to transform attribute before sending it to the target application (e.g G Suite).

  • We can create a rule in Okta saying “when our users try to access G Suite, take the user name part (e.g before @ in their email), and then append the domain that we have in Google to it.

  • I would recommend you to watch my video above to see its done, but let me also add some screenshots below if you prefer them.

 

  1. Go to Okta Admin Consoe and then to your G Suite application.
  2. Click on “Sign On” tab
  3. Click on “Edit” and scroll down to “Application Username Format”
Go to G Suite App in Okta
  • You would a few options here, you should first see if any of the provided options fit your needs.

  • If they do not, then select “Custom” which allows us to use Okta’s expression to create custom username.
Click on custom username
  1. Ensure you have clicked on “Custom” from the application username format dropdown.

  2. Here you should put the expression (based on¬†Okta’s expression language) which would result the required email address for your Google user.

    Example -: in below scenario, my users email in Okta is username@id.goldyarora.com, however my G Suite domain is @newDomain.com, so i want Okta to send the transformed email address in SAML (nameID)

    So, I will use the following Okta expression
    (String.substringBefore(user.email, “@”) +”@newDomain.com”)
    where Okta does the following-:
    (i) It first parses the username string which is before @
    (ii) Then it appends @newDomain.com to it.

     

  3. Now before you save your change, it is critical to ensure that your expression is correct and giving you the expected email address.
    For that, you can put any of your Okta user email in preview box (look at #3 in below screenshot)

  4. You should then check the result that preview gives you (look at #4 in screenshot below), this result should match this user’s Google username/email.

    You can then save the changes, now onwards, Okta would send the transformed email address (e.g user@newdomain.com in our example) to Google.

Transform the G Suite user name

We already have some users in Google, how would be manage user lifecycle via Okta?

Watch the video below if your users already exist in Google, and now you want to manage Google user lifecycle via Okta.

Manage User Provisioning via Okta when users already exist in Google
Play Video

We already have some users in Google, would they be deleted?

I have seen some cases where organizations start using G Suite (or Google Cloud Platform) before rolling out Okta.

Concerns-:

  • In this case, concern usually is lack of clarity about whether these Google users would be deleted or not once we start using Okta for provisioning (and SSO).

Solution-:

First of all, though we would need to do some work in this case, but rest assured, we can handle this situation without impacting users.

  • Okta provides an “Import Users” feature, which means we can import users from Google to Okta, and once these users are in Okta, we can assign them Okta user profile.

 There would be two scenarios in such case, and let us handle them one by one.

Scenario One -: Google users also exist in Okta

  • ¬†We can use Okta’s “Import Users” feature to bring these Google users to Okta, and once they are in Okta, we can create their Okta profile.

  • Result = These users would now have new Okta profile, so they can login to Okta, and G Suite would appear on their dashboard to access at one click (via SAML).

Scenario Two -: Google users do not exist in Okta

  • ¬†We can use Okta’s “Import Users” feature to bring these Google users to Okta, and because these users already have their Okta profile, we can map these users to their respective Okta account.

  • Result = These users would now see G Suite apps in their Okta dashboard to access with one click.

 

  1. Go to your G Suite application in Okta
  2. Click on “Import” tab
  3. Click on the “Import Now” button as shown in the screenshot below.
Go to G Suite import tab in Okta
  1. Okta should now start process of importing your Google users to Okta, it may take sometime depending on number of users in Google.
Note -: Please ensure you have already completed API integration setup as shown in provisioning section above, otherwise Okta would fail to import users because Okta would be calling Google’s Directory API to get these users.
G Suite Imort will start getting users in Okta
  • Okta should now show you the summary of how many users/groups scanned and imported to Okta
Okta would import the users from Google
  1. Now on this screen, Okta would show you whether the imported Google user has an Okta profile or not (based on user’s email address).

  2. If the Okta user does not exist, Otka would ask you to confirm new Okta account creation for this user.

  3. You should review and select the checkbox (look at #3 in screenshot below) to select all (or required users).

  4. Click on “Confirm Assignments” to confirm new Okta user account creation.

Note -: In case Okta user already exists with the same email address as of Google user, then instead of creating a new Okta account, it would ask you to confirm the mapping for existing account.

Map the new user from Google to Okta
  • Here you would do the final confirmation and tell Okta whether or not auto-activate users after confirmation.
Confirm Google user's Okta assignment

That is it, now your Google users are in Okta, and can login to G Suite via Okta SSO.

Okta would also not try to recreate them in Google, because it now knows that these Okta users are already in Google.

 

 

Important

Though everything should be working now for this specific use case, however if you look at assignment tab in G Suite app in Okta, you would find these users are individually assigned to G Suite application.

Though it is optional, but I would recommend you to convert their assignment from individual user to group based, so you can easily manage them via your AD or Okta groups.

You should follow these steps if you want to do that (or watch my video above)-:
(i) Disable the "Deactivate Users" (go to Okta --> G Suite App --> Provisioning Tab --> Edit)
(ii) Delete these users individual assignment (go to Okta --> G Suite App --> Assignment tab --> click on X mark)
(iii) Make sure these users are in your Group which you would be using for Google assignment.
(iv) Check the assignment, and these users should have Google app assignment based on your group assignment.
(v) Enable "Deactiave Users"
Recommended

GCDS vs Okta

In this section, let us talk some prominent differences between Okta and Google Cloud Directory Sync (GCDS), which one we should use in which scenario

Google Cloud Directory Sync and Okta both have their pros and cons which should be considered before making your decision to use them for managing your Google users and groups lifecycle.

You should ideally contact your Google or Google partner and Okta for recent developments in their products, however following table would help you as a starting point to understand some differences between these two utilities and recommendations for usage.

Scenario Rationale & Recommendation
Multiple Data Sources (e.g Multiple AD Forests) or Mergers & Aquisitions use cases Use Okta If-:

1. You already have all your identities provisioned in Okta (ideally they should be there, thats why you use IdPs).

2. You have multiple data sources (multiple AD Forests & HRMS systems) to bring your identities in Google

Use GCDS if-:

1. You have a single AD Forest to bring your identities to Google, though there are workarounds like spinning up multiple GCDS instances and leveraging exclusion rules, but it would not be easily manageable.

2. Your identities (that you want to provision in Google) are not in Okta.
Attribute Level Mastery If your provisioning requires attribute level mastery

For example-:
(i) Job title would come from workday.
(ii) Email will come from Active Directory.
(iii) Phone number will come from Ring Central.

Then use should Okta as GCDS does not provide attribute level mastery.

If all your attributes would be mastered from Active Directory (or LDAP), then you may use Google Cloud Directory Sync too based on other criteria in this table.
Write back to Active Directory GCDS does not write back to Active Directory, so you should use Okta for it, however GCDS and Okta can also be used in combination where you leverage GCDS for user lifecycle management, and Okta for write back to AD.
Org Unit Sync Use GCDS as it synchronizes OrgUnits well to Google, though you may be able to do it with Okta too, however it gets pretty messy as you would need to create lots of groups and assign priorities to it.
Shared Contacts Sync "Use Google Cloud Directory Sync as Okta does not sync Shared Contacts. (Shared Contacts = your external contacts like vendors, contractors etc)

Otherwise, because of other reaons you want to use Okta for provisioning, then you may use Shared Contacts API to separately manage shared contacts."
Resource Calendar Sync Use Google Cloud Directory Sync as Okta does not sync Resource Calendars. (Resource Calendars = Conference Rooms etc)

If because of other reaons you want to use Okta for provisioning, then you may use Calendar API to provision initial resources and then manage them in Google.
Attribute Transformation Use Okta if you have complex use cases which needs lot of attribute transformation (e.g if you want to send transformed attributes from AD to Google).

Though GCDS also let you transform attribute but only the domain name (e.g user@ad.local TO user@googledomain.com)
External members in Google Groups If you would have external members (e.g @yahoo.com) in your G Suite groups, then use GCDS as Okta doesn't manage/sync external members.
HRMS as a Master If you want to use your HRMS system (e.g Workday) as a master, then use Okta, as Google Cloud Directory Sync does not sync with HR Systems (only LDAP and AD)

Popular Okta Expressions

In this section, I would put some expressions based on Okta Expression language that might help if you have related use case.

Okta Expressions

To Parse the Organizational Unit from distinguishedName (dN)

Example –> Dn = CN=R A,OU=Third OU,DC=ad,DC=goldyarora,DC=com

Need to parse just the OU name, example ‚ÄúThird OU‚ÄĚ from above.

Expression -: 

String.substringAfter(String.replace(appuser.managerDn, “,DC=ad,DC=goldyarora,DC=com”,””), “OU=”)

Explanation -:

Following internal expression to remove ,DC=ad,DC=goldyarora,DC=com from the string, and then we are left with CN=R A,OU=Third OU

String.replace(appuser.managerDn, “,DC=ad,DC=goldyarora,DC=com”,””¬†

Outside string gets substring after the text after OU= in CN=R A,OU=Third OU

 

Parsing Manager’s Name from the CN

CN = “CN=R A,OU=Third OU,DC=ad,DC=goldyarora,DC=com”

String.substringBefore(user.manager, “,OU”) – get the part before ,OU

Now we are left with CN=R A

Add another express to to get the part after =

Combine above both expression into one-:

String.substringAfter(String.substringBefore(user.manager, “,OU”), “=”)

 

Replace any domain while sending to downstream app-:

String.replace(user.email,String.substringAfter(user.email,”@”),”gsuitedomain.com”)

Replace any domain name from input to G Suite one

 

Conditional Expressions-:

Syntax ==> [Condition] ? [Value if TRUE] : [Value if FALSE]

// smtp based on org name – multiple conditions

If you have multiple brands, and want to assign G Suite primary email based on brand, you can use conditional expression to check for user attribute and assign email based on it as shown in example below.

 

(user.organization == “Brand One”) ? (String.substringBefore(user.email, “@”) + “@brandone.com”) : (user.organization == “Brand Two”) ? (String.substringBefore(user.email, “@”) + “@brandtwo.com”) : (String.substringBefore(user.email, “@”) + “@catchall.com”)

In above expression, Okta checks for user.organization attribute value, if it is equal to “Brand One”, it assigns brandone domain to user, otherwise it goes to next condition and assign brandtwo.com if user belongs to Brand Two, if both conditions are false, Okta assigns catchall.com domain.

Okta Google Integration - FAQs

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

FAQ

Most frequent questions and answers about Google and Okta Provisioning and SSO Integration.

Okta intentionally does not delete users in Google, rather suspend them as you see here https://support.okta.com/help/s/article/Google-Apps-Deployment-Guide

I think it makes sense as deletion in Google is pretty sensitive, once you delete the account, you get 25 days to recover it, and if you miss it, your data is gone forever.

I have a script which you can leverage to unassign (or delete) users in bulk, you can access these scripts below-:

  1. Auto unassign G Suite licenses
  2. Delete G Suite users in bulk with Ok Goldy
You should not delete your Google users or unassign their G Suite licenses unless you know what you are doing, you should ideally unassign their G Suite Business or Enterprise license and assign G Suite Archive User License¬†so you pay less than regular G Suite license cost but still retain G Suite users’ data.

You should check for the following-:

  1. Have you configured “Network Masking”? If yes, make sure you use the IP address that is part of your IP range in Networking masking.

    Also, make sure you are not testing through mail.google.com, but rather mail.google.com/a/yourdomain.com
  2. Google Super Admins by pass SSO, so make sure you are testing with a regular Google user, and not a super admin one.
  3. SAML SSO is not supported on POP/IMAP, so ensure you are testing with Google Web application.

You should ensure that your Okta SAML response include valid Google ACS URL which can either be-:

https://www.google.com/a/yourdomain.com/acs

or

https://accounts.google.com/a/yourdomain.com/acs

and in case if you are getting the error “It means the Recipient attribute in the SAML Response does not match the Assertion Consumer Service (ACS) URL.” that means though you SAML includes the recipient but not the correct one as provided above.

This error indicates issues with your certificate (e.g private key used to sign SAML does not match your public key certificate that you uploaded to G Suite).

 

Please upload the right certificate again that you downloaded from Okta to G Suite and try again.

No, once Okta authenticates your user to Google, then a session is established between the user and Google which Okta do not control.

So you should define your session control in Google, which should ideally be less than your session configured in Okta.

You can read my blog post here about session control in G Suite or GCP.

You can not, as Google does not support multiple identity providers.

Though it depends on your scenario, but you might be able to manage this scenario within your Identity provider (e.g Okta).

For e.g -: If you have two set of users (which are different because of their domain name, or any attribute), and you want them to be authenticated via different Identity providers (e.g abc.com users should be authenticated against Okta, and xyz.com users should be via Azure).

You can do following in this specific use case-:

1. Configure required Identity provider in Okta (e.g Azure in above example use case).

2. Configure Google as service provider (with Okta as identity provider).

3. Create an IdP discovery rule in Okta which says (i) if the user is trying to access Google application AND (ii) user domain name is xyz.com, then Azure is the identity provider.

Now, when your xyz.com users try to authenticate to Google, they’ll be redirected to Okta –> Azure –> Okta –> Google, some of this interaction will be invisible to the end user though.

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

2 thoughts on “Definitive Guide to Okta & Google Integration”

  1. Hi Goldy, you produce SO GREAT content…we are happy users of your OKGoldy add-on when we deploy GSuite for our customers (we are a small GSuite Parter consultancy firm)

    Regarding OKTA.

    If ALL the “Saas” apps that our customer uses, have the option to sign on with their gsuite account, would you still recommend using OKTA?
    More and more webapps offer SSO with GSuite….

    Thanks a lot

    1. Your welcome Alvaro, glad I could help.
      regarding your Otka question : “Sign in with Google” is an OpenID way to login to those other applications, which indeed is more secure, and one should certainly use it being an individual.

      However if you are a G Customer, then ideally you should be using SAML (documentation here https://support.google.com/cloudidentity/topic/7558768), not because SAML is better than OIDC, but because Google offers controls on SAML.

      For e.g, you can decide who should get access to service applications via your G Suite / Cloud Identity id.

      Till today, Google does not provide option to block OIDC sign in (Sign as Google) for websites, though you can block OAuth scopes so your users can’t share it with 3rd parties other than their identity (openid scope only), but it still increases a bit of shadow it.

      So, today, i would recommend Google as your IdP (via SAML), instead of Okta if you are a G Suite / Cloud Identity customer.

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