G Suite Provisioning
About G Suite Provisioning
This guide provides information on how to configure provisioning for G Suite in your Okta orgThe Okta container that represents a real-world organization..
The recommended setup consists of the following:
- SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IdP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on an app, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. 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 DirectoryActive Directory (AD) is a directory service that Microsoft developed for the Windows domain networks. It is included in most Windows Server operating systems as a set of processes and services. Initially, Active Directory was only in charge of centralized domain management. integration is needed, the recommendation above still holds. The topology will look like the following:
With AD integration, end usersIn Okta literature, we generally refer to "end users" as the people who have their own Okta home page (My Applications), using apps to authenticate into all of their apps. End users do not have any administrative control. When we refer to "users" we are generally referring to the individual(s) who have administrative control. benefit from the following:
- Seamless Desktop SSOAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones. 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 AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. AppAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. 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 MasterA profile master is an application (usually a directory service such as Active Directory, or human capital management system such as Workday) that acts as a source of truth for user profile attributes. A user can only be mastered by a single application or directory at any one time. For more details, see the Profile Master page. When users are mastered by attribute, we call this attribute-level mastery (ALM). ALM delivers finer grain control over how profiles are mastered by allowing admins to specify different profile masters for individual attributes. Profile mastering only applies to Okta user profiles, not app user profiles. For more details, see Attribute Level Mastering. functionality, you need to have the following feature flags enabled. Contact Okta Support to have these enabled for your org:
The following ProvisioningProvisioning is the enterprise-wide configuration, deployment, and management of multiple types of IT system resources. Specifically, provisioning provides users access to equipment, software, or services. This involves creating, maintaining and deactivating required business process automation objects and attributes in systems, directories, and applications. features are supported:
GroupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with 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 DiscoveryAbility to import additional attributes to Okta, 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.