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.
Configuring the User Update Method
In the Identity Provider section of the SAML plugin, you can define the User Update Method.
The plugin provides 4 different methods.
| No User update | The plugin expects that all users do already exist in the application directories. Users that do not exist and try to log in, will receive an error. |
|---|---|
Update from SAML-Attributes (Just-in-Time Provisioning) | Users could be created or updated based on the attributes contained in the SAML response. |
| Update with UserSync-Connector | Admins can select a UserSync connector. With each SSO login, this connector performs a Single User Update to create or update a user. This is useful to have the active users up to date in between the periodic syncs. |
| Update with UserSync-Connector and apply SAML Attributes | This option allows you to combine information received via UserSync (run first) and enrich/ overwrite it with information in the SAML response. For the information from UserSync, the attribute mapping configured in UserSync applies. |
More information about Just-in-Time provisioning and User Sync can be found here.
Find user by attribute
When the app receives the SAML response after the user just authenticated on the Idp, it needs to find the user in the Atlassian product.
The Find user by this Jira attribute select box allows you to find the user from the SAML response in the Atlassian product either by
- searching for a user with that username
- searching for a user with that email address (provided the Idp sends the NameId in email format)
- searching for a user with a custom authentication attribute that you can create yourself
- that only works if you have something in place that makes sure all of your users have that attribute set; it's rather a special setting that is rarely used
The table below allows you to transform the NameId sent by Idp, should you not be able to configure the IdP to send it in the desired format. The value on the left-hand side (Attribute as received from <IdP>) refers to the User Name ID by default (the plain value of the NameID in the SAML response). You can use the template to strip the email domain from it or use the Custom template to apply more complex transformations. The latter also allows you to map a different field from the SAML response against it. So if you can't use the NameID, you could map it against the email address from the SAML response.
User Update Method - No User update
The plugin expects all users to be already provisioned. The only setting that can be configured is the Find user by attribute.
User Update Method - Update from SAML-Attributes
When selecting this method, an Attribute mapping table appears. In this table, the administrator can map attributes sent by the Identity provider during authentication to the user attributes from the application. This information can be used to update existing users or create new ones. With Atlassian, the administrator needs to have at least a mapping for the username, Full Name, and E-Mail Address in place to be able to create new users.
Most Identity Providers have already a preset configured that has the most common attributes used already mapped to the corresponding application user attributes. But each attribute can be edited and it is also possible to add and map new attributes for users. In case there is no preset and you would like to map the NameID from the SAML response for example to the username you need to enter ATTR_NAMEID as the attribute from the Identity Provider.
There is no extra mapping table for the Find user by attribute. Only the application attribute can be defined. The Attribute as received from <IdP> is taken from the mapping table below.
User Update Method - Update with UserSync-Connector
Here it is possible to link a User Sync connector to the SAML authentication configuration. The connector needs to be created first to show up here. Please follow our setup guides for User Sync to do so. User Sync does its periodic sync when it is configured but what happens when a new user logs in between those syncs or information were changed on the IdP side for existing users? Linking the User Sync connector here solves these questions. When having this in place every time a user logs in via SSO a Single User Update for this user is performed by User Sync. This would either create a new user or update existing ones even though the periodic full sync did not start yet.
There are 2 methods available to reactivate inactive users during the SSO login. By default, a user will be activated after successfully authenticating with the Identity Provider. (Reactivate inactive users during login). In case a Single User Update should activate an inactive user during the SSO login the Allow connector to set the user's active state box should be ticked.
There is also an extra mapping table for the Find user by attribute.
User Update Method - Update with UserSync-Connector and apply SAML Attributes
In some cases, certain attributes needed cannot be synced from the IdP via User Sync or should only be applied when a user successfully logs in via SSO and not during the actual full sync. For those cases, it is possible to configure a combination of both User Update Methods.
For the information from UserSync, the attribute mapping configured in UserSync applies. For the following update from the SAML response, the mapping from the Attribute Mapping table is important.
There is no extra mapping table for the Find user by attribute. Only the application attribute can be defined. The Attribute as received from <IdP> is taken from the Attribute Mapping table.