It is crucial to define the user's role in your Atlassian products and give them the proper global permissions, project permissions, and space permissions. It's how you will control any given user's level of access to the Atlassian application, irrespective of how they authenticate.
In large organizations and project-based organizations where permissions for collaboration tools frequently change, it is impractical to maintain users manually in the application. Consequently, many companies use a commercial identity provider (IDP) across their systems and applications.
IDP platforms enable the maintenance of user access control in a centralized fashion. It's the driving factor behind the popularity of cloud-based IDPs such as Microsoft’s Entra ID, Okta, Google GSuite, and OneLogin.
While all Atlassian products ship with LDAP support and Crowd, enabling you to use them with SSO, this approach favors on-premises solutions, and they may not work with your chosen cloud-based IDP.
To streamline admin processes for customers using cloud-based IDPs, Kantega SSO Enterprise provides three extended user provisioning capabilities:
Just-in-time provisioning: Create and update user accounts when users log in
SCIM: A standard provisioning protocol supported by most major providers
API Connectors: Synchronizes users via IDP-specific REST APIs
The table below lists pros and cons with the three cloud provisioning options, compared to LDAP and local administration.
Pro | Con | |
Just-in-time provisioning |
+ 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 can be difficult to configure on some IDPs - Users can set their own local passwords in the Atlassian application |
SCIM |
+ 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 do not support SCIM at the basic subscription tiers (for example, Microsoft requires a Platinum subscription for EntraID) |
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, this does not scale to very large directory sizes/companies (at a certain point, sync passes become too slow) - Has to be specifically implemented for each IDP - Currently only supported for Azure AD, Google GSuite, Keycloak, and Okta - API Connectors supports nested groups for Google Workspace and EntraID |
LDAP sync |
+ Built into Atlassian product + Easy integration with any LDAP-capable directory + Usually, the 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 |
Manual administration | + No setup |
- Does not scale well in terms of administrator workload - High risk for manual errors - Duplication of work (administrators must maintain user accounts manually at the identity provider level and within the Atlassian application) |
The Kantega SSO team has a decade of experience supporting global enterprise customers with complex user provisioning needs. Check out our related offerings and contact us any time to discuss your user provisioning needs.
Anna-Karin Østlie _Kantega SSO_
0 comments