Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Authentication via SSO (whether it’s SAML, OIDC, or Kerberos) does not remove the need for user accounts to exist in the Atlassian application. Roles or direct user assignment to global permissions, projects or spaces is still how you control any given user’s level of access to the Atlassian application, irrespective of how they actually authenticate.


  • Internal Directory: User accounts are managed inside the product and stored in the product database.

  • LDAP: Sync users and groups from on-prem or remote LDAP servers, ActiveDirectory being the most common.

  • Crowd: Manage users via on-premise Atlassian Crowd.

All of the above can work with SSO (though Crowd is usually redundant as it becomes a central user directory), but they’re also mainly on-premise. Kantega SSO Enterprise provides extended user provisioning capabilities, enabling user provisioning from cloud-based identity providers like Azure AD, Google GSuite, Okta, and OneLogin:

  • Just-in-time provisioning: Create and update user accounts when users log in.

  • API Connectors: Sync users via IDP-specific REST APIs.

  • SCIM: Standard provisioning protocol supported by most major providers.

The table gives an overview of the pros and cons for each.



Manual administration

No setup.

Does not scale well in terms of administrator work load.

Can be error-prone.

Duplicate admin work (user accounts must be manually maintained both at the identity provider and within the Atlassian application)

Active directory or LDAP sync

Built into Atlassian product.

Easy integration with any LDAP capable directory.

Usually best option in on-prem environments.

Limited or no support for cloud environments. While some vendors do provide LDAP adapters, they can be cumbersome to use.


Works with any IDP.

Technically simple: Users are created and updated from data passed through the browser, meaning no additional network dependencies.

Scales to “infinite” directory sizes.

Does not remove inactive users.

Group provisioning/claims can be difficult to configure on some IDPs.

Users are able to set their own local passwords in the Atlassian application.

API Connector

Ability to create, update and delete users automatically

Can be combined with local groups

Express filters and transformations within the Atlassian applications.

Synchronization/snapshot based, so does not scale to very large directory sizes/companies (at a certain point, sync passes simply become too slow).

Has to be specifically implemented for each IDP. Currently only supported for Azure AD, Google GSuite, and Okta.

API Connectors does not support nested groups.


In principle; works with any SCIMv2 compliant IDP.

Scales to any directory size.

SCIM also supports nested groups.

Requires inbound access to the Atlassian application. This has security implications/considerations. It also means more parts of the organization may need to be involved (networking/firewall etc).

Works best in the presence of failover, i.e. Atlassian Datacenter.

Some IDPs don’t provide SCIM at the basic subscription tiers. For example, a Platinum subscription is required for Azure AD.

A note regarding admin users


and websudo (secure admin sessions in Jira and Confluence)

Generally speaking, WebSudo websudo by using passwords is not possible with users provisioned by JIT, API Connectors, or SCIM. The WebSudo functionality requires a user account with a password, and the plugin This is because Kantega SSO cannot synchronize or obtain these the passwords from the identity provider. Authentication for such users is only possible via SSO, by redirecting to the identity provider. Users then authenticate in the IDP and are redirected back with a proof of identity, i.e. a SAML Response or an ID Token.

While it would technically be possible for the plugin to replace or hijack the WebSudo form, there is no way to reliably force re-authentication in the IDP, as a large number of them simply ignore or don’t support the standard forceAuthn flags. What would generally happen if we did redirect the WebSudo prompt to the IDP is:

  1. The admin opens Confluence for the first time.

  2. KSSO redirects to the identity provider.

  3. The user authenticates with username/password (and possibly 2FA).

  4. The IDP redirects back to Confluence with a SAML Response, and the user is logged in.

  5. The user tries to elevate permissions with WebSudo and is redirected to the IDP.

  6. The IDP recognizes the user from before and immediately redirects back to Confluence with a SAML Response or ID Token: No user input necessary.

Both from a user- and security perspective, this is exactly the same as having disabled WebSudo in the first place.

For admin accounts that need to use SSO, you basically have the following option:


Disable WebSudo as described for Jira:
For Confluence: Please navigate to the address:
<your_confluence_url>/admin/viewsecurityconfig.action and turn off the value “Secure administrator sessions”.


In version 5.1.0 of Kantega SSO re-login via the Identity Provider has been added to perform websudo (see below).


Please be aware that re-authentication requires your IdentityProvider to support the forceAuthn=true flag (for SAML), and prompt=login or max_age=0 flags for OIDC. Please verify that re-authentication works by clicking the Re-authenticate with SSO button and see that you are required to log in again (and not just bounce directly back to the admin pages). If you have a problem with re-login for your IdP, please contact us and we will see if there are any ways of enabling the support for this.


For JIT user accounts specifically, an admin can simply set a password manually, or the user can use the “forgot password” link. Note however that this password is not


synced with the identity provider password in any way. It also allows these users to bypass SSO and just authenticate directly with their password, unless you disable traditional login in KSSO.

In any case, we always recommend keeping at least one SuperAdmin superadmin user in the Internal Directory using a strong password, so that you can easily get back in case your SSO integration fails (certificate expiry, URL, and tenant changes, and so on).