[Legacy] Google GSuite

Owned by Jon Espen Ingvaldsen (Unlicensed)
Last updated: Mar 29, 2022 by Steinar Line
7 min read

This guide is for an older version of Kantega SSO Enterprise and is no longer maintained. New guides are here: https://kantega-sso.atlassian.net/l/c/rNTaTonz .

This guide takes you through the steps of setting up Google GSuite login to the following Atlassian applications:

  • Jira SERVER DATA CENTER

  • Confluence SERVER DATA CENTER

  • Bitbucket SERVER DATA CENTER

  • Bamboo SERVER

  • Fisheye / Crucible SERVER

 

 

You find a link to Atlassian Marketplace in the upper right corner of your Atlassian application. Click Manage apps and search for “Kantega”. Click “Free trial” or “Buy now” to install the app.

 

 

Add identity provider

A welcome message is shown when you select to configure the app for the very first time. Click “Start setup” and then “Setup SAML / OIDC”.

Select “Google GSuite” in the identity provider gallery.

Google GSuite allow you to setup single sign-on over both SAML and the OpenID Connect protocol. This knowledge base article describe the practical differences of these two protocols.

In the first wizard step, you select which SSO protocol to use. Click “Next”. Follow the protocol specific setup guides below.

 

1. Select provisioning method

The Atlassian applications needs to have information about users logging in and their permissions. At this wizard step, we choose whether user and permission data already exist when users log in with SSO or if user records should be created dynamically (just-in-time provisioning). Note that, Kantega SSO Enterprise does also offer cloud user provisioning with API Connectors for Google GSuite. This will give you a user directory that reads out user and permission data from GSuite and is always kept up-to-date and synchronized. More information about user provisioning alternatives are found here

If you want to utilize API Connectors to synchronize users, we recommend you to setup that before the setting up the SSO integration. When the synchronized user directory is up running, you can set up SSO and choose “Accounts already exist in <..> when logging in”.

Select provisioning method and click “Next”.

2. Configure identity provider

Go to https://admin.google.com

Select Apps in the main menu


Select SAML apps in the apps settings.

 

Press the round "+" button to add a new SAML app:

 

Enable SSO for SAML Application:

Press "Select my own custom app" link of the dialog window:


Google IdP Information: 

On this step only click to download Google's IDP metadata.

You will upload this metadata file in the next step of this setup wizard.

Basic Information for your Custom App

Use a descriptive name for your app, such as "JIRA". 

Then press “NEXT”.

 

Service Provider Details 

Copy the response URL from the setup wizard (back in the prepare step in the Kantega SSO wizard) into the ACS URL and Entity ID:

Leave other fields blank and press “NEXT”



Attribute Mapping 

On this step, add the correct mapping for attributes givenName, surname and email.

All of the fields should be of type "Basic Information"
Then press “FINISH” and “OK”. 

Enable the app for users

Make sure to set the "Service status" to "ON for everyone" on your GSuite SAML app.

If you want the Google login to only apply to a subset of the organization, you can choose "On for some". With this setting, users in other parts of the organization will be exposed with a "Service not enabled"-message after their username / password is given.

You may now close the G Suite browser window.

Click “Next” in the Kantega SSO wizard.

3. Import metadata

Upload the metadata file that we downloaded from Google during the identity provider configurations (previous step).

Click “Next”

4. Identity provider name

Fill in a name for your configuration, by default this is “Google GSuite”. Click “Next”

5. Verify signature

This step shows the certificate used to validate the SAML messages.

Click “Next”.

7. Summary

Validate your setup and click “Finish”.

 

8. Test and verify setup

On the next page you will be given a link to perform a test of your setup.

The test verifies that users are allowed to authenticate with the current configuration, and you get feedback on whether the current user is found in Atlassian application. You are also able to fix user lookup issues (selecting the right username attribute and express username transformation rules) and select data attributes for just-in-time provisioning here. More info about testing av verifying identity provider configurations.

6. Redirection mode

By default, Kantega SSO Enterprise will forward all users to the configured identity provider. However, you can configure both a subset of users who should be login through this identity provider and how they are redirected. More about configuration of redirection rules.

1. Select provisioning method

The Atlassian applications needs to have information about users logging in and their permissions. At this wizard step, we choose whether user and permission data already exist when users log in with SSO or if user records should be created dynamically (just-in-time provisioning). Note that, Kantega SSO Enterprise does also offer cloud user provisioning with API Connectors for Google GSuite. This will introduce a user directory that fetches user and permission data from GSuite and is always kept up-to-date and synchronized. More information about user provisioning alternatives are found here

If you want to utilize API Connectors to synchronize users, we recommend you to setup that before the setting up the SSO integration. When the synchronized user directory is up running, you can set up SSO and choose “Accounts already exist in <..> when logging in”.

You can also specify whether users logging in through Google GSuite should be added as members to a set of default groups automatically.

Select provisioning method, default groups and click “Next”.

2. Callback URL

The field “Callback URL” will be needed when configuring your identity provider. Copy this URL value (We will make use of this in the next step)

3. Configure identity provider

Sign in to https://console.developers.google.com/apis/credentials

In the Credentials page select “Create Credentials” and then “OAuth client ID”.

 

In the “Create OAuth client ID” page:

  • Set “Application type” to “Web application”

  • Give “Name” field a describing name.

  • Add one “Authorized redirect URIs” and copy the “Callback URL” from Kantega SSO as mentioned in the step above.

  • Then press “Create”

On “OAuth client created” page, copy the values of “Your Client ID” and “Your Client Secret” and keep these for use in step 6 below.

 

4. Import metadata

Go to the Kantega SSO wizard and click “Next” in the import step

 

5. Identity provider name

Fill in a name for your configuration, by default this is “Google GSuite”. Click “Next”

6. Client id and secret

On the “Credentials” step insert the values copied from Google “OAuth client created” page in step 3. Value of “Your Client ID” is put into “Client ID” and “Your Client Secret” is put in “Client Secret”.

Click “Next”, and you will see a summary page of your Kantega SSO setup.

7. Summary

Validate your setup and click “Finish”.

 

8. Test and verify setup

On the next page you will be given a link to perform a test of your setup.

The test verifies that users are allowed to authenticate with the current configuration, and you get feedback on whether the current user is found in Atlassian application. You are also able to fix user lookup issues (selecting the right username attribute and express username transformation rules) and select data attributes for just-in-time provisioning here. More info about testing av verifying identity provider configurations.

6. Redirection mode

By default, Kantega SSO Enterprise will forward all users to the configured identity provider. However, you can configure both a subset of users who should be login through this identity provider and how they are redirected. More about configuration of redirection rules.