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. Just In Time provisioning is an option for you when you cannot use LDAP. 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.
- 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.
- In contrast to Just In Time provisioning, users are updated periodically and not only when they log out and log in again.
- 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.
Just In Time Provisioning
If LDAP is no option 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, 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.
- 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.
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.