Introduction

Kantega SSO allow Atlassian applications to read user permission data as a part of SAML and OpenID Connect (OIDC) login flows. The handling of these permissions can be both managed and auto created.

See also

When using managed groups

Open

When a group is configured as Managed in Kantega SSO, the following will happen when a user logs in:

• If the SAML or OIDC response include a group claim for the managed group, the user is added as a member of the group.

• If no group claim is found for the managed group in the resonse, the user will be removed from the group.

Only groups which are explicitly configured as managed by Kantega SSO will be affected by this feature. All other groups are ignored, so you will still be able to manage some groups locally if you wish.

When using auto create groups

Open

When Auto create groups is selected as rule for group claims, Kantega SSO will create all groups and assign users to all claims included by the identity provider in the SAML or OIDC response.

If the switch Remove user’s group memberships is enabled, Kantega SSO will remove group memberships from users that does not exist in the incoming claim. In this way all group memberships that your identity provider has for a given user will be synchronized on each login.

From version 5.3.0 of Kantega SSO Enteprise, Auto create groups is also configurable to manage different cases for user creation: When should users be created (NEW).

User creation (Default): On every login

The default setting is to create users “On every login”, which follows just-in-time provisioning.

User creation: When the response contains groups

The second choice which also has presence in Managed Groups, is to “Only create users when the response contains groups”. This way, if an incoming user doesn’t have any group claims providing them rights, there is no point consuming another user on the license of the application. This allows you to configure groups on the Identity Provider.

User creation: Only when the response contains specific groups

The last choice in the new settings allows you to manage user creation based on specific incoming groups in the group claims. This way, you can ensure that even if a user has some group memberships in AD, at least one of the configured group memberships must be present in the group claims for the user to be created. This allows managing group memberships centrally from AD, but allows even more control in limiting creation of accounts that do not have access to any content in Atlassian anyway. This combines well with Authenticated “Anonymous” Browsing to limit the number of licenses in your instance, and allows for use cases where users with certain memberships are created when visiting Jira, while other employees will get anonymous, read-only access if they get a company-public page.

Configuring the identity provider

The first step is configuring the IDP to include group claims in authentication response messages (SAML) or UserInfo endpoint response (OIDC) when users log in. This is typically done in the IDP's administration console and depends on the IDP. We have included guides for some frequently requested IDPs. You may also consult your IDP's documentation or ask their support directly.

Test that the IDP is sending group claims

Once the identity provider is configured, run a SAML authentication test to verify that the identity provider actually sends the expected group claims. If group claims are detected, the test page will notify you of this and provide options for further configuration.

The example test result below shows that the user is a member of the jira-software-users group:

In the test results page, the following change to the managed group during login may appear:

Also "No change" and "Will be removed" are valid messages for changes for Managed groups.