Important Update Effective February 1, 2024!
Due to recent changes in Jira and Confluence, we've made the tough decision to discontinue the OpenID Connect (OIDC)/OAuth app and no longer provide new versions for the newest Jira/Confluence releases as of January 31, 2024.
This is due to some necessary components no longer shipping with Jira/Confluence, which would require some extensive rewrites of the OIDC App.
Important Update! This app will be discontinued soon!
Due to recent changes in Jira, which no longer ships with some components required for our Read Receipts app to run, we've made the tough decision to discontinue the app, as of Februar 5, 2025.
Important Update! This app will be discontinued soon!
We've made the tough business decision to discontinue the app, as of January 11, 2025.
Selecting the Right Provisioning Model for You
The SAML SSO plugin supports different styles for provisioning users. When you decide to you use our plugin, you need to pick a model. In essence, you have to decide how users are created and updated in your Atlassian product. Depending on your needs, one or more approaches work for you. Each model has their own advantages and disadvantages. But, we recommend to use LDAP or User Sync. Just In Time provisioning is an option for you when you cannot use LDAP or User Sync. It has less features, but still has administration benefits for you. Creating users manually is also an option. But since it has a high administrational effort, we do not recommend it.
In the following, this article will introduce each provisioning model with their advantages and disadvantages.
Overview
The following provisioning models are supported by the SAML SSO plugin:
- LDAP: Allows to sync users (periodically) via a LDAP server.
- User Sync: Also allows to sync users (periodically) from Azure AD, Okta or GSuite.
- Just in Time (JIT) provisioning: Create and update Jira users on-the-fly when they log in via the SAML attributes.
- Manual User management: Create users "by hand" on both the IdP and your Atlassian product's side
LDAP
With a connection to a LDAP server, users will (periodically) synced to your Atlassian product instance. LDAP offers a variety of configuration options. For a more detailed look, please see the official Atlassian documentation.
Advantages
- If you already have a LDAP setup, you can keep using it. You only need to configure the SAML SSO plugin and everything will work.
- Users can be synced before their first log in. This allows to use them in your Atlassian product, even before they first logged in.
- During the login, our plugin also allows to search LDAP for newly created or updated users. Thus, updates on the LDAP can be synced even between sync intervals.
- In contrast to Just In Time provisioning, users are updated periodically and when they log in. Users provisioned with Just in Time are only updated when they log in and log out.
- LDAP allows for advanced filtering for users/groups to be synced.
- Users can also log in with their local passwords if the SSO stops working for any reason. When a user tries to log in with their password, Jira will connect to the LDAP for signing in the user.
Disadvantages
- The username and password which is used to authenticate your Atlassian product with the LDAP server is saved in cleartext in the database of your Atlassian product. But if you set up your server correctly, this should not be an issue. Please a have look at the Atlassian documentation (see section "Server settings"), if you are concerned about this.
User Sync
User Sync is a new feature of our SAML SSO plugin. It allows to (periodically) sync users from Azure AD, Okta, GSuite, Keycloak and OneLogin to your Atlassian product instance. It provides functions similar to LDAP and can be used if LDAP is not an option for you.
Advantages
- Similar advantages than LDAP
- User Sync has even more advanced functionality:
- Allows for group transformations. If you have a group at your IdP, but you want to rename it for your Atlassian product, User Sync can do this. E.g. a group called "users" on the Idp side can be transferred to "jira-users" for Jira.
- Assign local groups automatically. E.g. for a Confluence instance, assign "confluence-users" automatically.
- Black/White listing. Block certain groups from being synced or only allow special groups to be synced.
- Use a Cron expression for scheduling a sync.
Disadvantages
- In contrast to LDAP, users can not log in with their local password. No passwords will be synced and there is no mechanism for User Sync to ask the IdP to validate the user.
- It is currently only available for Jira, Confluence, Bitbucket and Bamboo. Additionally, only Azure AD, Okta, GSuite, Keycloak and OneLogin are supported as of the time of writing.
Just In Time Provisioning
If LDAP and User Sync are no options for you, you can still use Just In Time (JIT) provisioning. JIT creates and updates users on-the-fly via the SAML attributes when they log in into your Atlassian product (see Create or update users through SAML Attributes). Setting up JIT is more effort then LDAP or User Sync, but since it uses SAML attributes it is always an option to lower your administration effort.
Advantages
- Users will only be created when needed.
- Users also can be updated.
- It is also possible to send group memberships via SAML attributes, thus updating the groups of a user. But there are limitations for Azure AD (see Disadvantages)
- Lowers your administration efforts in comparison to manage users manually.
Disadvantages
- You cannot disable users.
- Similar to User Sync, users are also not able to login with their password if single sign on fails for any reason.
- Users only get created after their first log in, thus you cannot assign users to projects or tickets before their first login.
- If you modify your user at your IdP, users only get updated after they log out and log in again. In consequence, when you assign or remove groups from users or change their profile, your Atlassian product will only be update the users, when they log out and log in again.
- For Azure AD, there is also a special restriction:
- In contrast to other IdPs, Azure AD only transmits group ids via the SAML attributes, e.g. "42" instead of the group name. If you only have a small amount of groups and you do not really add new groups often, you can use the group transformation feature of our SAML plugin to create a special group mapping. E.g. "42" then can be mapped to a group name. But, this is only feasible when you only have a low number of groups, since you have to create the group transformations for each group by hand.
- GSuite does not support groups via SAML attributes.
Manual User Management
When even JIT is not an option for you, you can still create and update users manually on both the IdP and your Atlassian product's side. This results in a high administration effort and allows for making mistakes. But for completeness, it is also possible create and update users manually.