[Legacy] AD FS

You find a link to the 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.

Open

1. Select provisioning method

The Atlassian applications need to have information about users logging in and their permissions. At this wizard step, we choose whether the user and permission data already exist in a user directory when users log in with SSO or if user records should be created dynamically (just-in-time provisioning).

You can also specify whether users logging in through AD FS 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 provider

The easiest way to prepare AD FS is by using Powershell. Copy the command and paste it into an elevated Powershell window.

Make sure you are accessing the application using https.

Login to your AD FS server and start a Powershell terminal window as an administrator. Then copy/paste the generated Powershell script into the terminal window and run it.

Confluence is now added as a relying party in AD FS.

Click “Next.”

3. Import metadata

Type the hostname of your AD FS server in the import step of the Kantega SSO wizard. Importing metadata using the AD FS hostname is recommended, as it allows for automatically updating certificates. 

Click “Next.”

4. Identity provider name

Fill in a name for your configuration. By default, this is “AD FS.” 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 the 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 the configuration of redirection rules.

1. Verify the version of Windows Server

Verify that AD FS is running on Windows Server 2016 TP4 or later. Please use SAML for older versions that do not support OIDC.

2. Select provisioning method

The Atlassian applications need to have information about users logging in and their permissions. At this wizard step, we choose whether the user and permission data already exist in a user directory when users log in with SSO or if user records should be created dynamically (just-in-time provisioning).

You can also specify whether users logging in through AD FS should be added as members to a set of default groups automatically. Such configurations are available after the initial setup.

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

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

4. Configure AD FS identity provider

On your Windows Server 2016 TP4 or later server, Open the AD FS Management console on the AD FS server. Right-click on Application Groups and select Add Application Group.

• Give the app a name and select the “Server application accessing a web API.

• Click “Next.”

• Copy the Client Identifier value. We will use this id later.

• Add the callback URL from the Kantega SSO wizard into the list of Redirect URIs.

• Click “Next.”

• Click to generate a shared secret and copy the shared secret. We will make use of it later.

• Click “Next.”

Add your site’s URL in the Identifier list (in our example https://issues.example.com). Press Next.

• Select “Permit everyone” in “Choose an access control policy.”

• Press Next.

• Let openid be the Permitted scopes as is the default.

• Press Next.

• Verify everything looks correct on the summary screen and

• Click “Next” and then “Close.”

   

5. Import metadata

Press Next in Kantega SSO to get the Metadata import step. Write in the ADFS host and click “Next.”

6. Identity provider name

Fill in a name for your configuration. By default, this is “AD.” Click “Next”

7. Client id and secret

Insert the client credentials in the Client Identifier and shared secret retrieved during step “4. Configure AD FS identity provider” above. Click “Next.”

8. Summary

Validate your setup and click “Finish.”

9. 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 the 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 and verifying identity provider configurations.

10. 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 the configuration of redirection rules.