About Google Workspace Provisioning
This guide provides information on how to configure provisioning for Google Workspace in your Okta org.
The recommended setup consists of the following:
- SAML configured between Okta and Google.
- Enable provisioning and have all the options enabled.
- In particular, enabling password push synchronizes a user's Okta login password with their Google Workspace password - since a password is still needed for clients such as POP3/IMAP clients for email.
Where Active Directory integration is needed, the recommendation above still holds. The topology will look like the following:
With AD integration, end users benefit from the following:
- Seamless Desktop SSO when logging in behind the firewall
- SAML into Google Workspace via Okta using AD credentials when outside the firewall.
- Email clients requiring username/password now leverage the users' AD password - one less password for the end user to remember. This is accomplished through AD password synchronization.
- For SSO, SAML should be the goal. This enables centralized access management since all web-based sessions have to go through Okta as the identity provider.
- SAML should be tested with a small group of users first. Using the Network masks feature in Google, you can limit the SAML-enabled users to a small audience (for example, several IT staff) to test out the configuration and the end user experience.
- It is important to let your end users know about the need to modify account settings in order to use Google Personal and Google Workspace together in the same browser session. This setting is independent of whether or not Okta has been deployed. It is needed by Google to allow sharing of session cookies.
- Be aware that some apps from Google Market place may not be as tightly integrated as they should be with Google Workspace in terms of SSO. Let Okta know about any issues and Okta support will help you solve any problems that may arise.
- Passwords in Google Workspace are still recommended. Okta recommends enabling the password synchronization feature with Google Workspace. The Change Password URL should be configured to point users back to Okta if they try to change their passwords from within Google Workspace when password synchronization is turned on. The URL will take the user back to Okta.
- Make sure the availability and use of the backdoor URL is well understood among administrators. A Google Workspace Admin App is also available in the application catalog.
- When enabling provisioning, choose the admin credentials used for the integration carefully. Ideally, use a system account. If an end user account is used, make sure password reset is handled correctly and that the Okta API settings are updated accordingly.
- If Google Workspace users are going to be created primarily in Google Workspace with an existing process outside of Okta, then account creation need not be enabled in Okta. User import (through API or CSV) can easily map existing Google Workspace accounts with Okta users. This should be done in an ongoing fashion to bootstrap new users.
- Okta recommends enabling user deactivation/reactivation to ensure automated deactivation happens when a user is deactivated in Okta or in AD which is integrated with Okta.
Before configuring provisioning in Okta, you need to do the following:
Enable API Access checkbox in Google Workspaces as follows:
Sign in to your Google Workspace admin console.
Go to Security > API Controls.
In order to user Profile Sourcing functionality, you need to have the following feature flags enabled. Contact Okta Support to have these enabled for your org:
The following Provisioning features are supported:
New users created in the third party application will be downloaded and turned in to new AppUser objects, for matching against existing OKTA users.
Specifically: This is an implicit feature when provisioning is configured - meaning with the username/password set up and verified. Import allows Okta to map active Google accounts to an Okta user. This is usual for the initial app assignment bootstrap. CSV can also be used for file-based account mapping - similar to what API import can do.
Import additional user attributes from Google Workspace.
New users created through Okta will also be created in the third party application.
New users created through Okta will also be created in the third party application.
Specifically: Account creation allows Okta to create new accounts in Google Workspace. It is important to note that Google Workspace does not allow the reuse of a recently deleted username (1 week restriction) for a new account. The Google Workspace user will go through a welcome-routine from Google when they first login
Changes made to the user's password will be automatically synchronized to the application.
Specifically: This feature allows Okta to synchronize the password used by the Okta user to log in to Okta, then into Google Workspace. If a user is not associated with an AD account, or Okta-delegated authentication to AD is not enabled, then the user logs into Okta with their Okta password. That is the value that will be pushed out to Google Workspace.
If a user is tied to an AD user and Okta-delegated authentication to AD is enabled, then the AD password will be pushed out to Google Workspace when the user logs into their Okta org (ie. myorg.okta.com)
Even with SAML enabled, there are use cases where a password is needed in Google Workspace. Other mail, calendar clients (desktop or mobile) utilize a separate authentication mechanism and will require a Google Workspace user name and password for setup. Synchronizing the password with Okta means one less password to managed by the end user. This is a standard deployment model for many existing Okta customers.
Note: Okta password policy should match Google's requirements in order for provisioning to work.
Updates made to the user's profile through Okta will be pushed to the third party application.
Specifically: Any profile changes detected in Okta will be pushed to Google Workspace. This includes first name, last name, etc. Some attributes, such as department and title, are only used for push profile and will not work for import user. Those attributes only work if they were initially updated from Okta.
Deactivating the user through Okta will remove the user from the organization and all teams in the third party application. Reactivating the user through Okta will reactivate the user in the 3rd party application.
Specifically: Okta deactivates a user's Google Workspace account when the user is deactivated in Okta. While Google Workspace allows an account to be completely deleted in Google Workspace, the deletion is a rather destructive operation that removes all emails, documents, pages, etc created by this user. For most enterprises, this is not the desired operation. Okta sets the user to the inactive state - allowing administrators to go in and clean things up before deciding on whether a hard deletion is necessary.
Configure your Provisioning settings for Google Workspace as follows:
In Okta, select the Provisioning for the Google Workspace app, then click Configure API Integration.
Check the Enable API integration box, then click Authenticate with Google Workspace:
Enter your Google Workspace Admin account credentials, then click Log In:
Enter your admin username:
Enter your admin password:
Review the list of permissions Google will grant Okta to perform in your Google Workspace tenant. If acceptable clickAllow:
- You are returned to the Provisioning page in Okta where you should see authentication success messages. Click Save.
Select To App, then select the Provisioning features you want to enable.
Select To Okta, then check Allow Google Workspace to source Okta users.
When a user is deactivated within Google Workspace, you can choose what action Okta will take against the matching Okta user by using the Profile and Lifecycle Sourcing options.
The options for When a user is deactivated in the app are:
Do nothing: Like other apps, the Okta user will simply be unassigned the Google Workspace app.
Deactivate: The Okta user will become deactivated and will no longer be able to login or access Okta. If re-activated in Google Workspace in the future, the Okta user will go through the re-activation process in Okta. The user will need to go through the initial Okta user setup steps again.
Suspend: The Okta user will become suspended and will no longer be able to login or access Okta. If re-activated in Google Workspace in the future, the user will become re-activated in Okta and no further steps are needed for the Okta user to be able to log in.
To assign users to the Google Workspace app:
Open the app, select the Assignments tab, then click Assign to People:
In the Assign Google Workspace app to People dialog, select a user, then click Assign:
You can select which Organizational unit will be pushed, set Deactivation options and Manage licenses for users (for more information see Managing Google Workspace Users):
By default, the following base attributes are imported from Google Workspace:
Google Workspace also supports User's Schema Discovery, so you can add extra attributes to User's Profile.
In Okta, from the Admin dashboard, select Directory > Profile Editor.
Select the APPS section in the left navigation bar, then find your app in the list.
Check the list of attributes, and if you decide you need more, click Add Attribute. A list of extended attributes appears:
Select the attributes you want to add, then click Save.
You can now import and push these user attribute values to or from Google Workspace.