About G Suite Provisioning
This guide provides information on how to configure provisioning for G Suite 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 G Suite 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 G Suite 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 G Suite 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 G Suite in terms of SSO. Let Okta know about any issues and Okta support will help you solve any problems that may arise.
- Passwords in G Suite are still recommended. Okta recommends enabling the password synchronization feature with G Suite. The Change Password URL should be configured to point users back to Okta if they try to change their passwords from within G Suite 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 G Suite 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 G Suite users are going to be created primarily in G Suite 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 G Suite 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 Apps as follows:
Sign in to your Google Apps admin console.
Navigate to Security > API Reference > API Access.
Check Enable API Access:
In order to user Profile Master 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:
Groups and their members can be pushed to remote systems. More about using group push operations you can find here: Using Group Push.
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 G Suite.
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 G Suite. It is important to note that G Suite does not allow the reuse of a recently deleted username (1 week restriction) for a new account. The G Suite 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 G Suite. 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 G Suite.
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 G Suite 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 G Suite. Other mail, calendar clients (desktop or mobile) utilize a separate authentication mechanism and will require a G Suite 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 G Suite. 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 G Suite account when the user is deactivated in Okta. While G Suite allows an account to be completely deleted in G Suite, 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 G Suite as follows:
In Okta, select the Provisioning for the G Suite app, then click Configure API Integration.
Check the Enable API integration box, then click Authenticate with G Suite:
Enter your G Suite 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 GSuite 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 G Suite to master Okta users:
When a user is deactivated within G Suite, you can choose what action Okta will take against the matching Okta user by using the Profile and Lifecycle Mastering 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 G Suite app.
Deactivate: The Okta user will become deactivated and will no longer be able to login or access Okta. If re-activated in G Suite 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 G Suite 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 G Suite app:
Open the app, select the Assignments tab, then click Assign to People:
In the Assign G Suite 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 G Suite Users):
By default, the following base attributes are imported from G Suite:
G Suite 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 G Suite.