Note |
---|
This guide is for an older version of Kantega SSO Enterprise and is no longer maintained. You will find a guide for the latest version of Kantega SSO Enterprise here: Okta |
This guide takes you through the steps of setting up Okta login to the following Atlassian applications:
Jira
Status colour Blue title SERVER Status colour Blue title DATA CENTER Confluence
Status colour Blue title SERVER Status colour Blue title DATA CENTER Bitbucket
Status colour Blue title SERVER Status colour Blue title DATA CENTER Bamboo
Status colour Blue title SERVER Fisheye / Crucible
Status colour Blue title SERVER
Expand | ||
---|---|---|
| ||
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 “Okta” in the identity provider gallery.
Okta 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.
Expand | ||
---|---|---|
| ||
1. Select provisioning methodThe 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 Okta. This will give you a user directory that reads out user and permission data from Okta and is always kept up-to-date and synchronized. More information about user provisioning alternatives are found here
You can also specify whether users logging in through Okta should be added as members to a set of default groups automatically. Alternatively, you can also retrieve and assign group memberships individually based on attributes in the SAML response. Such configurations are available after the initial setup. Select provisioning method, default groups and click “Next”. 2. Configure identity providerLogin to Okta as an admin user. Click the "Admin" button in the header. Click “Developer Console” up to the right and select “Classic UI”. Click the "Applications" link in the header. In the application page, click "Add Application". Then, click "Create New App". Choose "Web" as platform and "SAML 2.0" as sign on method. Enter an app name in General Settings. Optionally upload a logo, and click "Next". Copy the response URL from the setup wizard (back in the Kantega SSO configuration) into the fields "Single sign on URL" and "Audience URI (SP Entry ID)". In "Attribute statements", set up the following attributes:
Click “Next”, then “Finish”. Right click on the "Identity Provider metadata" link (see illustration above) and copy the URL to your clipboard. You will need this link in the next step of this wizard. Assign People and/or Groups to your appNow Okta users needs be assigned to (which means to get access to) your application. Click the "Assignments" tab. Further, when you click the green "Assign" button, you can choose to assign users individually or through their group memberships. To assign a group to your application:
To assign people individually:
3. Import metadataBack in the Kantega SSO setup wizard you can now press "Next" to get to the import step. Paste in the metadata url (See instructions above regarding copying metadata url from Okta). Click “Next”. 4. Identity provider nameFill in a name for your configuration, by default this is “Okta”. Click “Next” 5. Verify signatureThis step shows the certificate used to validate the SAML messages. Click “Next”. 7. SummaryValidate your setup and click “Finish”.
8. Test and verify setupOn 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 modeBy 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 redirection rules. |
Expand | ||
---|---|---|
| ||
1. Select provisioning methodThe 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 Okta. This will give you a user directory that reads out user and permission data from Okta and is always kept up-to-date and synchronized. More information about user provisioning alternatives are found here
You can also specify whether users logging in through Okta should be added as members to a set of default groups automatically. Alternatively, you can also retrieve and assign group memberships individually based on attributes in the SAML response. Such configurations are available after the initial setup. Select provisioning method, default groups and click “Next”. 2. Callback URLThe 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 providerLogin to Okta as an admin user. Click the "Admin" button in the header. Click “Developer Console” up to the right and select “Classic UI”. Click the "Applications" link in the header. In the application page, click "Add Application". Then, click "Create New App". Choose "Web" as platform and "OpenID Connect" as sign on method and click Create. Give the app a name (we named it “Confluence” in the example below), and past in the “Callback URL” from the Kantega SSO wizard into the Login redirect URIs. Click Save. Assign People and/or Groups to your appNow Okta users needs be assigned to (which means to get access to) your application. Click the "Assignments" tab. Further, when you click the green "Assign" button, you can choose to assign users individually or through their group memberships. To assign a group to your application:
To assign people individually:
4. Import metadataGo to the Kantega SSO wizard and click “Next” in the import step 5. Identity provider nameFill in a name for your configuration, by default this is “Google GSuite”. Click “Next” 6. Client id and secretIn this step, we will insert client credentials from Okta. These two values are found in the Okta settings at the bottom of the “General” tab in the app settings: Click “Next”, and you will see a summary page of your Kantega SSO setup. 7. SummaryValidate your setup and click “Finish”. 8. Test and verify setupOn 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 modeBy 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 redirection rules. |