SAML SSO Troubleshooting Guide for Jira Data Center

Summary

Integrating Single Sign-On (SSO) or Security Assertion Markup Language (SAML) with JIRA (or Service Management) using supported identity providers such as (Microsoft Azure Active Directory, Okta, OneLogin…) can be quite complex. There are numerous factors that could cause this integration to fail. The issues may stem from misconfigurations either on the JIRA application side or within the identity provider's settings.

SAML integration expects both Identity Provider IdP (Okta, OneLogin,,) and Service Provider (Jira, Confluence,,) to have information on users, and an agreement that is done with SAML protocol. The protocol implementation requires certain information to be exchanged by both parties accordingly. Failure to do the information exchange according to the SAML configuration and/or protocol and its implementation or failure to have correct information on users causes SAML Authentication to fail.

This KB article lists the root causes that have been identified so far, which are known to prevent JIRA Administrators/users from successfully configuring, authorizing, and testing SSO/SAML configuration.

Environment

JIRA Service Management 5.15.0 / JIRA 8.15 and higher

Diagnosis

• Check in the SSO/SAML configuration ⚙ > System > Authentication methods

• Navigate to ⚙️ → System → Logging and Profiling

• Add these packages one by one and turn them on for DEBUG logging > Save.

• com.onelogin.saml2 and com.atlassian.plugins.authentication

• Generate HAR file while trying to replicate the issue.

• Generate a new support zip.

Cause

Root Cause 1 - Found Attribute element with duplicated Name

• When a user tries to log in to JIRA using SSO, the user faces a Found Attribute element with duplicated Name error in the atlassian-JIRA.log file.

• The error occurs when IDP sends duplicate attribute names via SAML response.

• For more information about this root cause, please refer to the KB article Found an Attribute element with duplicated Name error while users tries to login using SSO

Root Cause 2 - Attribute [XXX-YYY-ZZZ] could not be found

• When attempting to log in after configuring SAML SSO for JIRA Data Center, login fails and an error similar to the example below is seen in the atlassian-JIRA.log file:

• The JIT provisioning field 'Groups' does not support mapping expressions and requires only the name of an attribute/claim containing a list of group names. In this example, 'JIRA-software-users' is a value passed for the group attribute from the Identity Provider (IDP) that contains a list of group names. This problem will continue so long as the JIT provisioning field 'Groups' does not contain the correct attribute name.

• For more information about this root cause, please refer to the KB article JIRA SAML error Attribute could not be found

Root Cause 3 - Received invalid SAML response: Could not initialize class com.sun.org.apache.xerces.internal.impl.dv.xs.SchemaDVFactoryImpl

• After configuring SAML in JIRA and attempting to login, the login fails and the following error is observed in the atlassian-JIRA.log

• The Java version on the server where JIRA is hosted was updated while JIRA was running. In order for JIRA to use the new version of Java, JIRA must be restarted.

• For more information about this root cause, please refer to the KB article SAML logins fail with class initialization error in JIRA Server

Root Cause 4 - A valid SubjectConfirmation was not found on this Response: SubjectConfirmationData doesn't match a valid Recipient

• After configuring JIRA Data Center SAML the following error may be observed,the following appears in the atlassian-JIRA.log

• This indicates a mismatch between the Recipient of the SubjectConfirmationData section received in the SAML Response with compared to the URL used in JIRA and can be caused by either:

• A mismatch of the base URL configured in the server.xml cause the same error or

• The wrong connector ("JIRA (On-prem)") is being used on OneLogin side.

• For more information about this root cause, please refer to the KB article Received invalid SAML response: A valid SubjectConfirmation was not found on this Response: SubjectConfirmationData doesn't match a valid Recipient

Root Cause 5 - Received invalid SAML response: Invalid issuer in the Assertion/Response

• After setting up SAML with JIRA Data Center, the user is redirected to JIRA but not logged in. The following error appears in atlassian-JIRA.log

• Invalid issuer in the Assertion/Response suggests that the issuer value in the SAML assertion does not match the entity ID.

• The difference can be as simple as the protocol in the URL (https vs http).

• For more information about this root cause, please refer to the KB article SAML login fails with "Invalid issuer in the Assertion/Response"

Root Cause 6 - Received SSO request for user XXXX, but the user does not exist

• After enabling SAML Single Sign-On (SSO) for JIRA, user is unable to log in. The following errors appears in the atlassian-JIRA.log

• User does not have permission to log in to JIRA or the username being sent by the IdP does not match the username in JIRA.

• For more information about this root cause, please refer to the KB article User unable to log in after enabling SAML Single Sign On for JIRA

Root Cause 7 - Received invalid SAML response https://JIRA.atlassian.com is not a valid audience for this Response

• After enabling SAML Single Sign-On (SSO) for JIRA, user is unable to log in. One of the following errors appears in the atlassian-JIRA.log

• This indicates a mismatch between the Audience URL(Entity ID) given by JIRA during the SAML configuration and the Identity Provider. In ADFS 3.0 the Audience URL(Entity ID) is referred to as the Relying Party Identifier. These values must match exactly.

• If JIRA provides an Audience URL(Entity ID) of https://JIRA.atlassian.com and the Identity Provider is configured as:

  https://JIRA.atlassian.com/ the Audiences will not be considered matching because of the trailing / in the second URL and the above error will be seen.

• For more information about this root cause, please refer to the KB article Received invalid SAML response: is not a valid audience for this Response

Root Cause 8 - NullPointerException at com.google.common.collect.Iterables.getOnlyElement() when logging in with SAML SSO

• After enabling SAML Single Sign-On (SSO) for JIRA, user is unable to log in. One of the following errors appears in the atlassian-JIRA.log

• The most common cause of this error is when the Username mapping setting has been incorrectly set when configuring SAML SSO in JIRA. This causes JIRA to be unable to retrieve the username attribute, the missing attribute then causes a NullPointerException.

• For more information about this root cause, please refer to the KB article NullPointerException at com.google.common.collect.Iterables.getOnlyElement() when logging in with SAML SSO

Root Cause 9 - Received invalid SAML response: The response was received at <ANOTHER_URL>/plugins/servlet/samlconsumer instead of <BASE_URL>/plugins/servlet/samlconsumer

• After enabling SAML Single Sign-On (SSO) for JIRA, user is unable to log in. One of the following errors appears in the atlassian-JIRA.log

• This error occurs after a change to the JIRA base URL, if the same change isn't applied to the proxyName parameter in server.xml.

• For more information about this root cause, please refer to the KB article SAML SSO fails with "We couldn't log you in. This may be for a variety of reason. We suggest trying again."

Root Cause 10 - 400 Bad Request

• Browsing through the UI after installing third-party SAML SSO for JIRA display problem will be visible.

• Header size is too big for certain requests. Increasing the value on Tomcat should help in this case.

• For more information about this root cause, please refer to the KB article Layout problems due to a cookie size after installation of third party SSO

Root Cause 11 - Browser redirects other applications to HTTPS when using the same domain/subdomain as JIRA

• Applications deployed on the same JIRA DNS are being forced to HTTPs by the browser when JIRA is using SSL, even if they don't use SSL.

• For more information about this root cause, please refer to the KB article Browser redirects other applications to HTTPS when using the same domain/subdomain as JIRA

Root Cause 12 - User's sessions swapping

• When User A logs out and logs back in, the system's Single Sign-On (SSO) feature doesn't prompt for re-entry of credentials. Upon re-login, the system displays the avatar of a different user, not User A's. However, as User A continues to navigate the site, their avatar reverts back to normal.

• When User A visits the same page that User B is viewing, the page begins to refresh endlessly and the avatar changes to User B's. Having this behavior depends on who navigated to the page last.

• For more information about this root cause, please refer to the KB article User's sessions swapping

Root Cause 13 - No subject alternative DNS name matching DOMAIN.COM found

• The connection to the LDAP fails with the an error "handling exception: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching DOMAIN.COM found."One of the following errors appears in the atlassian-JIRA.log

• There are multiple causes, please check KB for more details "No subject alternative DNS name found", Certificate with correct hostname is imported.

Root Cause 14 - Received invalid SAML response: Signature validation failed. SAML Response rejected.

• After enabling SAML Single Sign-On (SSO) for JIRA, a user is unable to log in. One of the following errors appears in the atlassian-JIRA.log

• There are multiple causes, please check KB for more details Received invalid SAML response: Signature validation failed. SAML Response rejected.

Solution

Solution for Root Cause 1

• Ensure the IDP don't send multiple values for theRole attribute and should review IDP configuration in such a case.

• For more information, refer to the KB article Found an Attribute element with duplicated Name error while users tries to login using SSO

Solution for Root Cause 2

• Change the JIT provisioning field 'Groups' to the name of the attribute configured on the IDP that contains a list of group names.

• The JIT provisioning field 'Groups' does not support mapping expressions and requires only the name of an attribute/claim containing a list of group names. In this example, 'JIRA-software-users' is a value passed for the group attribute from the Identity Provider (IDP) that contains a list of group names. This problem will continue so long as the JIT provisioning field 'Groups' does not contain the correct attribute name.

• For more information about this root cause, please refer to the KB article JIRA SAML error Attribute could not be found

Solution for Root Cause 3

• Generate a support zip and review the application.xml file located in the application-properties folder.

• Search for the <sun.boot.library.path> or <java.version>.

• Compare the results to the java version returned by running the command: java -version on the server where JIRA is hosted.

• If the versions are different, you will need to restart JIRA to correct.

• For more information about this root cause, please refer to the KB article SAML logins fail with class initialization error in JIRA Server

Solution for Root Cause 4

• Ensure the Recipient of the SubjectConfirmationData returned by the SAML response matches.

• For more information about this root cause, please refer to the KB article Received invalid SAML response: A valid SubjectConfirmation was not found on this Response: SubjectConfirmationData doesn't match a valid Recipient

Solution for Root Cause 5

• Review the Single sign-on issuer (a.k.a. entity ID) in your SAML setup on the JIRA side.

• Run through How to view a SAML responses in your browser for troubleshooting and review the Issuer in the SAML assertion.

• For more information about this root cause, please refer to the KB article SAML login fails with "Invalid issuer in the Assertion/Response"

Solution for Root Cause 6

• Correct the username so it matches what is expected by JIRA. Typically this should be fixed on the IdP's side, making the IdP return the expected user name as the NameId.

• For more information about this root cause, please refer to the KB article User unable to log in after enabling SAML Single Sign On for JIRA

Solution for Root Cause 7

• Ensure the Identity Provider(IdP) Relying Party Identifier matches character for character with the provided Audience URL(Entity ID) in the JIRA SAML configuration.

• For more information about this root cause, please refer to the KB article Received invalid SAML response: is not a valid audience for this Response

Solution for Root Cause 8

• Check with your SSO provider to confirm which SAML attribute contains the username, and change the Username mapping setting to the correct value.

• For more information about this root cause, please refer to the KB article NullPointerException at com.google.common.collect.Iterables.getOnlyElement() when logging in with SAML SSO

Solution for Root Cause 9

• Apply the change to server.xml and restart JIRA.

• When retesting immediately after the change, make sure to be on incognito mode.

• For more information about this root cause, please refer to the KB article SAML SSO fails with "We couldn't log you in. This may be for a variety of reason. We suggest trying again."

Solution for Root Cause 10

• Header size is too big for certain requests. Increasing the value on Tomcat should help in this case.

• For more information about this root cause, please refer to the KB article Layout problems due to a cookie size after installation of third party SSO

Solution for Root Cause 11

• Applications deployed on the same JIRA DNS are being forced to HTTPs by the browser when JIRA is using SSL, even if they don't use SSL.

• For more information about this root cause, please refer to the KB article Browser redirects other applications to HTTPS when using the same domain/subdomain as JIRA

Solution for Root Cause 12

1. F5 Load Balancer:

   1. Check with your LB administrator if a Load Balancing Stickiness Strategy is in place. This is needed for a DC cluster to properly work.

   2. Check if any Web Acceleration Profile configuration is in place. This might be caching users' sessions and mixing them up.

2. CloudFront: Cache mechanism. This has been found as a cause for the misbehavior.

3. Apache web server: Please see Frequent logouts and Session swap / hijack in JIRAandRequest Assumes Identity of Another User who Logs in Concurrently Due to Apache CacheIgnoreHeaders

4. For more information about this root cause, please refer to the KB article User's sessions swapping

Solution for Root Cause 13

• There are multiple causes and solutions, please check KB for more details "No subject alternative DNS name found", Certificate with correct hostname is imported.

Solution for Root Cause 14

• There are multiple causes and solutions, please check KB for more details Received invalid SAML response: Signature validation failed. SAML Response rejected.