This post will illustrate how to integrate Okta and Google workspace, options of integration and how to migrate users or stage the migration, the authentication flows and inbound federation.
The post includes videos to illustrate how the integration works.
The implementation was done on a small scale and in testing environments. Any production application should be reviewed and planned accordingly without solely relying on this post
Overview
Google Workspace, like many other applications, is currently integrated with Okta. As more SaaS services become SAML 2.0 capable, or if not, OIDC capable, integrating other systems for identity authentication becomes simpler and easier.
While we focus on exploring the options available with Google Workspace and Okta, we will also cover a general perspective on the protocols and methods used, which can be applied to different applications.
Generally the application integration can be staged in parts,
- Authentication
- Provisioning
- Assignment
Google Workspace Application
Start by adding the google application from Applications -> Applications -> Catalog then filter to find the application
Add the integration and start the initial setup
The next page will take you to the settings option either Secure Web Authentication or SAML2.0
SSO SAML 2.0 Option 1: Manual
After choosing this option, there will be detailed steps to follow from view setup instructions
The values will be populated automatically,
Keep the window open and download the verification certificate
Go to Google admin console -> Security -> Authentication -> SSO with third party IdP
Add SAML profile and then substitute the values from Okta
Then once saved the profile will have the SP details, from the RPID value can be found
Note: There is option to configure the SSO profile to the entire org, however using third party profile will add more flexibility to apply it later on
Go back to Okta and update the value
At this stage the federation should be ready, one last step is to add the profile to the organization for authentication to happen with Okta.
Then assign the profile
As you can see above there are 2 options
- Have Google prompt for their username, then redirect them to this profile’s IDP sign-in page
- Require users to enter their Google username and password to sign in
The first option will apply the SP-initiated flow which means users will be redirected to Okta to authenticate when they login directly to Google account
The second option will allow the user to login with username and password normally, however they can still federate and access through Okta in IdP-Initiated flow
Note: At the beginning of the migration, you might allow users to log in directly with their Google username and password. Once all users are migrated or created in Okta, you can remove this option and always redirect users to Okta.
Remember, users must be in Okta before redirecting them there. Therefore, ensure that before enforcing authentication with Okta, you have either manually added the users or provisioned them through SCIM. In both cases, users must activate their accounts in Okta
Below video from testing org to illustrate the entire process
SSO SAML 2.0 Option 2: 1-click
At some point where you need to integrate multiple different google tenants, using 1-click can make the configuration for the SAML part much faster
To enable the feature, go to Settings -> Features.
Currently its in EA as of the date of writing this post
Then start the google integration similar to part1, this time once you choose SAML, another option will show for 1-click
Then connect your google account, this account will also be used for provisioning covered later in user provisioning part
Allow the access
The RPID will also be automatically updated, the next step will be to check the Google admin console
There is a new profile ready to use, under Manage SSO profiles assign the profile to the organization unit
1-click, will make it easy to configure the integration in easy fashion, the provisioning part must be enabled and save then you can start provisioning without additional authentication
Organization Unit For SAML Testing
The OU can be created and tested in case you want to have phased approach towards authenticating with Okta
To do this first create OU in Google, Directory -> Organization Units
The OU will inherent the security settings from parent org
Then go to Security -> SSO with third-party IDPs -> Manage SSO profile assignments, under the OU click on it and manage the assign the SAML profile
This will make sure that only users under the OU will have the SAML settings rest of the org will not be part of the SSO profile
User Provisioning
The user provisioning is the part that enables Okta to communicate with the application using SCIM and be able to bring users to Okta also enable Okta to Create, Update, Deactivate the user in the downstream application. Overall making the lifecycle of user centralized and automated.
Will start the provisioning after creating the application.
Use the default options and authenticate with google account
Allow the access after that save the configuration
Then the options for provisioning will be available
- Okta to App
- App to Okta
Okta To Google Workspace
For Google Workspace, Okta supports multiple operations
By default nothing is enabled, the first 3 are important for lifecycle management
With password sync option, its possible to sync user password with Google or sync a random password in Google for the user
Random password sync will not allow the user to login to google using password.As mentioned in previous section that is possible to allow username/password to login to google directly, this scenario with random password will be best if you always intent to use Okta as source of truth with no options for password login
Google Workspace To Okta
Multiple options are available, if there will be plans to schedule import this can be enabled in general also the user format
The user can be imported if there is a match; if not, a new user will be created.
The option to confirm can be automatically available. This option will be useful when the scheduled import is configured.
Below Video explains the user provisioning part
Application Assignment
The final step in achieving a functional integration is to assign users to the application so they can authenticate through Okta and access Google.
Users can be assigned without provisioning as long as they are created manually in Google.
If provisioning is enabled, then more options are available for application assignment
Below Video cover this process
Inbound Federation with Google Workspace
To enable inbound federation which means allowing users to login to Okta using their Google account, in this case admins must build trust between Okta and Google workspace in order to allow a login option using Google then create a Identity provider routing rule in Okta for this option to work
To configure inbound federation, there are 2 steps
- Identity Provider
- Routing rules
Note:
Inbound federation mainly used for use cases like allowing the contractors to login to Okta, be careful when configuring both application integration and inbound federation with same target to avoid being stuck in authentication loop, If it is required then make sure to allow users to login directly to Google Workspace without being redirected to Okta as mentioned in the previous section ‘SSO SAML 2.0 Option 1: Manual’
Identity Provider
First go to Security -> Identity Provider:
Choose Google Idp and next
At this stage, you will need to go to https://console.cloud.google.com/
then create a new project
The consent must be configured at first before adding credentials, go to API & Services -> OAuth consent screen
Then configure the application name and authorized domains
Save and then define the scope
Email, Profile and openid
Update and continue to the summary page to view the configuration
Now go back to the credentials page and create credentials
The choose the application type Web application
It’s very important to add the correct authorized URI towards your tenant
Once created the Client ID and Client Secret will be available
Now go back to Okta and add the Client id and Client Secret
There are more options like account linking ,,etc if you need to modify or enable account linking change the default settings below
In this example leave the default options and then Finish, if some users already exist you can enable the account linking policy which will link the account to the existing one
Routing Rules
Routing rules, is the way how Okta can detect which users to forward them to Identity provider or prompt an option for users to login using Google
from routing rule
add a new rule
In this rule i allowed to show google as login option by choosing the idp to also have google as option to login
Then Activate the rule to take effect
From routing rules, there is option to choose different routing logic to avoid having Google as option and only route the user to Google once specific condition matched
This will redirect the user based on the domain they try to login from, so users will put their username@example.com then Okta will redirect to Google
Below user experience for this configuration
References
https://help.okta.com/en-us/content/topics/provisioning/google/google-provisioning.htm
