...
PROS | CONS | |
|---|---|---|
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. | |
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). API Connectors does not support supports nested groups for Google Workspace and Azure AD. | |
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. |
...
Generally speaking, websudo by using passwords is not possible with users provisioned by JIT, API Connectors, or SCIM. This is because Kantega SSO cannot synchronize or obtain the passwords from the identity provider for such users. 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. In version 5.1.0 of Kantega SSO re-login via a SAML or OIDC based Identity Provider has been added to perform websudo (see below image).
...
In any case, we always recommend keeping at least one 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).
A note about cloud user provisioning and passwords
When you set up user provisioning from cloud user databases as described above (either via SCIM or API Connectors) users will not have their passwords synced. This means that these users are not able to use their passwords locally in Jira, Confluence, Bitbucket and Bamboo, which is no problem when you set up login using SAML, OIDC or Kerberos, but it will naturally not work to use username/password login locally in the Atlassian products.
Git operations for users created via cloud user provisioned
As described in the above section users created via cloud user provisioning will not have a local password. Therefore, such users that want to do git operations against Bitbucket will not be able to authenticate with username and password. The way to authenticate from git is therefore by using SSH keys as is built in support for in Bitbucket. A guide from Atlassian on how each user can create his SSH key is found here:
https://confluence.atlassian.com/bitbucketserver/ssh-user-keys-for-personal-use-776639793.html
Also using the API tokens feature in Kantega SSO for git authentication is supported. Then you must enable the /scm endpoint in the API token access section (see below):
...
And each user that wants to use API tokens must create his own token and use git URLs like this:git clone https://<username>:<128-chars-API-token>@bitbucket-test.example.com/scm/test/test.git