• Google Apps 
• Single Sign-On
• Lifecycle Management

Single Sign-On

G Suite supports SAML 2.0. The setup is relatively straightforward through the admin console when one is logging in as a G Suite Admin.

SAML

G Suite SAML configuration supports both Service-provider (SP) initiated and Identity-provider (IDP) initiated SAML negotiation.

1. For IDP-initiated SAML, an assertion is sent out from Okta when a user tries to access G Suite by clicking on the app icon on his Okta home page.

2. For SP-initiated SAML, a user hits a deep link that is tied to their G Suite domain (for eg. [https://mail.mydomain.com] or [https://https://docs.google.com/a/mydomain.com]). Based on the "Sign-in page URL" setting, G Suite redirects back to Okta. A user will be required to log in to Okta. In the case where Desktop SSO is configured with the Active Directory domain, Okta will automatically log in the user and SAML into G Suite if a G Suite deep link is being accessed.

3. Network masks can be used to control the users affected by SAML. According to Google - "Network masks determine which addresses will be affected by single sign-on. If no masks are specified, SSO functionality will be applied to the entire network".

4. Use a semicolon to separate the masks, for example: (64.233.187.99/8; 72.14.0.0/16). Use this feature to control the rollout or for initial testing of a small population of users.

A few important points about G Suite SAML configuration:

1. With the recent G Suite migration, cookie sharing between apps within G Suite and also with the personal account has been integrated.

2. Previously, users had no problem logging into G Suite and Google Personal simultaneously in a single browser. This is still supported today - but it requires end users to go into Account Settings and enable the Multiple Sign-In feature. This needs to be done in both the G Suite account and the personal account.

3. SAML support between the core G Suite (mail, docs, calendar) is well supported. We have observed some issues with some of the applications in the G Suite Marketplace. While they share the same G Suite user name, the SAML support is not extended to those apps, and as a result, the user is still prompted for credentials.

4. User Password in G Suite may still be relevant even with SAML enabled. While SAML authentication itself does not require a password, the password may still be needed for client configuration with IMAP email client on the desktop (e.g. Outlook, Mac Mail) or mobile devices. See Managing Users for more information on password synchronization with G Suite.

5. The Sign-In URL property is active even if the Enable Single Sign-On check box is unchecked. So, while SAML is not active, users will still be re-directed back to Okta for login. When disabling SAML, make sure that the 3 URL fields are also blank out.

6. Backdoor URL. There is a backdoor URL that allows an administrator to login using their username and password regardless of whether SAML is enabled or not. The G Suite Admin app in Okta provides this backdoor login. It is strongly recommended that G Suite admin be provisioned with this app. The actual URL is in the form of [https://www.google.com/a/mydomain.com]. A login form (a green login prompt) will show up. Only admins can log in through this page.

Managing Users

Okta's provisioning features enable integration with the G Suite Provisioning Web Services API. The integration requires a username and password of an admin user. The following features are supported:
 

• Password Synchronization

This allows Okta to synchronize the password used by the Okta user to log in to Okta, then into G Suite. If the user is not associated with his AD account, or Okta-delegated authentication to AD is not enabled, then the user logs into Okta with his Okta password. That is the value that will be pushed out to G Suite.

If the 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 and calendar clients (desktop or mobile) utilize a separate authentication mechanism and will require a G Suite username and password for setup. Synchronizing the password with Okta means one less password to be 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. 

• Account Creation

Account creation allows Okta to create new accounts in G Suite. NOTE: 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.

• Account Deactivation/Re-activation

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.

• Profile Update

Any profile changes detected in Okta will be pushed to G Suite. This includes first name, last name, etc.

• Account Import

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.

• Google Organizational Units (OUs)

Google Organizational Units (OUs) are typically used to grant access to various resources within G Suite, such as access to Drive, Gmail, Calendar, and G Suite Marketplace. A user can only be assigned to one OU at one time. OUs are different from Google Groups, which are email aliases used as listservs.

Okta automatically imports valid OU values from G Suite. An OU value is simply represented as a user attribute in Okta. Okta can provision a user with an OU value and subsequently push changes to G Suite. 

NOTE: If an existing OU is renamed, moved, or deleted in G Suite, Okta updates the valid OU values on the next import. However, existing Okta users that were previously assigned to the changed OU are not updated since it is not clear what OU the user should be moved to. Instead, Okta shows that the user is assigned the default “/” root OU and does not push this attribute. The Admin needs to manually select a new OU for the Okta user, which then triggers an update to G Suite. 

• Profile Editor with Universal Directory

With Universal Directory enabled, the integration can provision and import an expanded set of user attributes. These attributes and mappings can be viewed, edited, and expanded in the Profile Editor.

NOTE: The G Suite User Username attribute shown in the Profile Editor is equivalent to the Primary Email attribute in G Suite. There is no separate G Suite User Primary Email attribute. This is because G Suite uses Primary Email as the unique identifier/username to login to G Suite. The Primary Email also doubles as the G Suite User’s Gmail email address.

• Provisioning Credentials

Admin user credentials are needed to enable provisioning in Okta. With password synchronization enabled, if Okta detects that the username whose password is being updated matches that of the API username, Okta will not synchronize the password into G Suite to ensure the API continues functioning.

After configuring the provisioning options and wanting to test it out, sign out of Google with the user account used for testing provisioning.
 

Recommended Setup

The recommended setup consists of the following:

1. SAML to be configured between Okta and Google.

2. Enable provisioning and have all the options enabled.

3. 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.

With AD integration, end users benefit from the following:

1. Seamless Desktop SSO when logging in behind the firewall

2. SAML into G Suite via Okta using AD credentials when outside the firewall.

3. 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.

Rollout Recommendation

1. 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.

2. SAML should be tested with a small group of users first. Using the "Network masks" feature in Google. Limit the SAML-enabled users to a small audience (e.g., several IT folks) to test the configuration and end-user experience.

3. It is important to let the 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 the sharing of session cookies.

4. Be aware that some apps from Google Marketplace 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 solve any problems that may arise.

5. 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.

6. 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.

7. When enabling provisioning, choose the admin credentials used for the integration carefully. Ideally, use a system account. If an end-user account is used, ensure password reset is handled correctly and the Okta API settings are updated accordingly.

8. 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.

9. 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.

Contingency Plan for Disabling SSO

In the case where SSO needs to be disabled between Okta and G Suite immediately, do the following:

1. Admin logs into G Suite using the backdoor URL ([http://www.google.com/a/mydomain.com]) 

2. Select Advanced Tools > Set up single sign-on (SSO).

3. Uncheck Enable Single Sign-on.

4. Un-specify (blank out) the 3 URL fields.

5. Select Save Changes.

6. The username/password login page re-appears for all end users when they try to access G Suite. There might be a lag of 30 seconds before this kicks in.

Known Issues

• The Search bar in People > Profile Editor > G Suite User > Add Attribute sequence cannot search for multi-word attribute names that contain spaces.

• The G Suite User profile shows a separate Primary Email attribute. This is because the G Suite instance was created prior to the January 2015 GA update and is a deprecated implementation. A best practice is to setup a brand new G Suite instance in the Okta org, and de-activate the old one. If this is not feasible, it is fine to continue using the existing G Suite instance, but do not map any Okta user attribute to the G Suite User Primary Email attribute.

• After provisioning a user to G Suite, the Contacts app does not show the updated user profile. This is expected behavior as it takes up to 24 hours for updated values to appear in the G Suite Directory section of the Contacts app.

Google API / UI Attribute Inconsistency

Okta attributes are mapped to the Google User Schema in the Google Directory API. In some cases, the Google Admin UI and Contacts app UI are inconsistent with this Google User Schema. For example, an attribute value might not show up in the UI, even though it's correctly populated via the API. Additionally, an attribute value entered in the Google Admin UI might not show up in the Google User Schema properly. Google has communicated that they are aware of this inconsistency between UIs and API, and are working to resolve it. In general, query the Directory API directly to determine whether Okta has correctly pushed user profiles to Google. The following provides additional details on the impact of this inconsistency in specific use cases and how to work around them.

Validate User Data in the Google User Schema

Use the Google API Explorer tool to validate user data in the Google User Schema: 

1. Go to: https://developers.google.com/apis-explorer/#s/admin/directory_v1/directory.users.get.

2. Authenticate Oauth with default scopes.

3. Enter the primary email of the desired user in the userKey field.
   
   

User creation in G Suite from Okta

The following G Suite User base attribute values created in Okta and pushed to G Suite will not show up in the Contacts app and Google Admin UI, but they will show up in the API:

• Second email
• Street address
• City
• State
• Zip code
• Country code

User import from G Suite

By default, Okta does not import some user attributes entered via the Google Admin UI. This is because these attribute values are incorrectly exposed in the Google User Schema via API. This issue may get resolved at some point by Google, but the suggested workaround is to use a tool like GAM to reconfigure the attribute values such that Okta can import them. Note that this issue only affects imports from G Suite. Provisioning of attributes from Okta to G Suite works successfully.

User import from Google, and then subsequent update from Okta

For a G Suite User who was originally created in Google Admin UI, updating their profile in Okta will not overwrite attribute values that were originally populated in G Suite UI and to which Okta does not explicitly map.  For example, if "Cost Center" attribute is first filled out in Google Admin UI, then updating "Organizations costCenter" in Okta will not result in a Google Admin UI update. By contrast, if "Phone (Work)" attribute is first filled out in Google Admin UI, then updating "Primary phone" in Okta will result in an update in the Google Admin UI.
 

Related References

• Single Sign-On documentation from Google

• Google Admin SDK's Directory API from Google