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.
Create or update users through SAML Attributes
The SAML Single Sign On plugins for Atlassian Data Center can automatically create users on the first Single Sign On login or update them on all further logins (Just in time provisioning). For the creation or updating process, the user informations are taken from the SAML Assertions attributes within the SAML Response. New users are created on default in the application internal directory and tagged by the plugin.
Only users with this tag are updated on following logins (except feature Update existing users is active). So If you have created the user manually within the application (before or after introducing the plugin doesn't matter), the user is not updated if the data in the SAML Response differs from the user data. This especially applies to group memberships.
Video Guide
Configurations
Identity Provider configurations
Set up your Identity Provider to deliver attributes for userid, email address, full name and optional group assignments in the SAML reponse. The configurations for the Identity Provider attribute mapping is always different. Please check your Identity Provider documentation for further informations/help.
The SAML Response can be found in the Authentication Tracker (Troubleshooting) or in the application log file with enabled plugin DEBUG log output (Enable-detailed-logging).
This is an example SAML Response for a user "camilla" with full name "Camilla the Chicken", email address "camilla@muppets.com" and groups "jira-testgroup1,jira-testgroup2":
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" Destination="https://jira7sd.lab.inserve.local/plugins/servlet/samlsso" ID="_2d7d3fe5-a2a1-45b5-93de-a39e27d7ff2d" InResponseTo="ldjedifipldjoefccdnlomjmlebmmieomblnfopn" IssueInstant="2016-02-11T22:01:28.284Z" Version="2.0">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://dc01.ad.lab.inserve.local/adfs/services/trust</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="_958e90f3-5d10-4d92-b376-45b9bb6db68d" IssueInstant="2016-02-11T22:01:28.284Z" Version="2.0">
<Issuer>http://dc01.ad.lab.inserve.local/adfs/services/trust</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
...
</ds:Signature>
<Subject>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo="enefpfnmgckjadiephjbdhacakigkiooonkonjgl" NotOnOrAfter="2016-02-11T22:27:46.519Z" Recipient="https://jira7sd.lab.inserve.local/plugins/servlet/samlsso"/>
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2016-02-11T22:22:46.503Z" NotOnOrAfter="2016-02-11T23:22:46.503Z">
<AudienceRestriction>
<Audience>https://jira7sd.lab.inserve.local/plugins/servlet/samlsso</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname">
<AttributeValue>camilla</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
<AttributeValue>Camilla the Chicken</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
<AttributeValue>camilla@muppets.com</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
<AttributeValue>camilla@muppets.com</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/role">
<AttributeValue>jira-testgroup1,jira-testgroup2</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2016-02-11T21:43:25.002Z">
<AuthnContext>
<AuthnContextClassRef>urn:federation:authentication:windows</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>
SAML Single Sign On for Data Center configuration
- Go to the configuration page of the SAML SSO for Data Center app
- Enable the checkbox Enable User Creation or Update (Enable user update + Create new users in the newer versions) to activate the creation/update functionality. The enabled checkbox opens the attribute fields for further configurations.
- Enter or select the SAML attribute names delivered by the Identity Provider for Userid, Full Name, Email and Group. If you have imported metadata containing friendly names for these attributes, you can use the select boxes.
- Save the configurations.
- Perform a Single Sign On and check if the user is correctly created/updated by all sent informations from the Identity Provider (SAML Attributes).
Advanced informations/configurations for group mapping
All groups need to already exist in Jira for group assingment, unless you enable the Add nonexisting Groups checkbox. So please ensure that all required groups are created manually in the application or the groups creation checkbox is enabled, before using the Single Sign On.
Group Attribute:
The user is assigned to all existing group values of the defined Group attribute in the SAML Response. Which groups are sent via the SAML Response depend on your Identity Provider attribute mapping configurations as well as the user assigned groups on your Identity Provider.
User Groups:
Every user, which use the SSO for authentication, is assigned to the defined groups in the User Groups field. This functionality is optional and mainly intended to give all users access permissions for the application, when using the Single Sign On for the first time. If not every user should receive the defined groups, you would need to remove this groups and assign them via the Group Attribute to your users.
- Flll the User Groups field with an appropriate group name:
- For customers/users using the Single Sign On for the Service Desk Customer Portal, there is own field called JIRA SD Customer Groups:
The group assignments of the Group Attribute and the User Groups field are completely independent of each other and can be combined if needed.