Users not in the Crowd SSO directory but existing in other directories in Jira are denied login in spite of having the right permissions

Related content

  • No related content found

Still need help?

The Atlassian Community is here for you.

Ask the community


Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.

Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Summary


Normally, when a user is logging in, Jira checks the directories defined in Administration > User Management > User Directories and first tries to authenticate the user in the first directory in the list. If the user is not found there it goes on to check with the second directory, and so on. However, if you are using the old SSO method with Crowd where Jira has been configured to use a specific 'SSOSeraphAuthenticator' class is replacing the regular 'SeraphAuthenticator' in the seraph-config.xml file only the Crowd SSO directory will be consulted to authenticate users. Other directories will not be checked.

Environment

  • Jira Data Center
  • Crowd SSO (Single Sign-On)
  • com.atlassian.jira.security.login.SSOSeraphAuthenticator authenticator uncommented in '[JIRA_INSTALL_DIR]/atlassian-jira/WEB-INF/classes/seraph-config.xml' (as described in the Integrating Crowd with Atlassian Jira documentation)

Diagnosis

  • There are more than one directory defined in Jira under Administration > User Management > User Directories
  • Users in any of the directories other than the first (the Crowd SSO directory) are denied access to Jira
  • The user in question exists in the 'jira-users' group, is configured to have access to Jira and the correct password is supplied
  • Turning on DEBUG level logging for package com.atlassian.crowd results in logging like this:

    • In 'atlassian-jira.log'

      2024-04-05 16:10:07,649+0200 http-nio-127.0.0.1-8080-exec-102 url: /jira/rest/gadget/1.0/login DEBUG anonymous 970x18226761x7 2jejkin 10.12.3.23,127.0.0.1 /rest/gadget/1.0/login [c.a.c.manager.application.ApplicationServiceGeneric] Trying to authenticate user 'affecteduser' in directory 'Crowd Server (10340)' for application 'crowd-embedded'
2024-04-05 16:10:07,649+0200 http-nio-127.0.0.1-8080-exec-102 url: /jira/rest/gadget/1.0/login DEBUG anonymous 970x18226761x7 2jejkin 10.12.3.23,127.0.0.1 /rest/gadget/1.0/login [c.a.c.i.rest.service.RestExecutor] Constructed https://jirabase.url/crowd/rest/usermanagement/1/authentication?username=affecteduser
2024-04-05 16:10:07,701+0200 http-nio-127.0.0.1-8080-exec-102 url: /jira/rest/gadget/1.0/login DEBUG anonymous 970x18226761x7 2jejkin 10.12.3.23,127.0.0.1 /rest/gadget/1.0/login [c.a.c.i.rest.service.RestExecutor] Cache response for POST https://jirabase.url/crowd/rest/usermanagement/1/authentication?username=affecteduser was CACHE_MISS
2024-04-05 16:10:07,703+0200 http-nio-127.0.0.1-8080-exec-102 url: /jira/rest/gadget/1.0/login DEBUG anonymous 970x18226761x7 2jejkin 10.12.3.23,127.0.0.1 /rest/gadget/1.0/login [c.a.c.manager.application.ApplicationServiceGeneric] User 'affecteduser' does not exist in directory 'Crowd Server (10340)', continuing
2024-04-05 16:10:07,704+0200 http-nio-127.0.0.1-8080-exec-102 url: /jira/rest/gadget/1.0/login DEBUG anonymous 970x18226761x7 2jejkin 10.12.3.23,127.0.0.1 /rest/gadget/1.0/login [c.a.c.manager.application.ApplicationServiceGeneric] Trying to authenticate user 'affecteduser' in directory 'Jira Internal Directory (1)' for application 'crowd-embedded'
2024-04-05 16:10:07,778+0200 http-nio-127.0.0.1-8080-exec-102 url: /jira/rest/gadget/1.0/login DEBUG anonymous 970x18226761x7 2jejkin 10.12.3.23,127.0.0.1 /rest/gadget/1.0/login [c.a.c.manager.application.ApplicationServiceGeneric] Authenticated user 'affecteduser' in directory 'Jira Internal Directory (1)' for application 'crowd-embedded'
2024-04-05 16:10:07,844+0200 http-nio-127.0.0.1-8080-exec-102 url: /jira/rest/gadget/1.0/login INFO anonymous 970x18226761x7 2jejkin 10.12.3.23,127.0.0.1 /rest/gadget/1.0/login [c.a.c.integration.seraph.CrowdAuthenticator] Account with name <affecteduser> failed to authenticate
com.atlassian.crowd.exception.InvalidAuthenticationException: Account with name <affecteduser> failed to authenticate

    • In 'atlassian-jira-security.log'

      2024-04-05 16:10:07,846+0200 http-nio-127.0.0.1-8080-exec-102 url: /jira/rest/gadget/1.0/login anonymous 970x18226761x7 1girejn 10.12.3.23,127.0.0.1 /rest/gadget/1.0/login login : 'affecteduser' tried to login but they do not have USE permission or weren't found. Deleting remember me cookie.
2024-04-05 16:10:07,892+0200 http-nio-127.0.0.1-8080-exec-102 url: /jira/rest/gadget/1.0/login anonymous 970x18226761x7 1girejn 10.12.3.23,127.0.0.1 /rest/gadget/1.0/login The user 'affecteduser' has FAILED authentication.  Failure count equals 1



Cause

The com.atlassian.jira.security.login.SSOSeraphAuthenticator authenticator class only checks the SSO Crowd directory and is not aware of any other directories that may have been configured in Jira. This is as designed. 


Note that the logging from [c.a.c.manager.application.ApplicationServiceGeneric] above states that Jira did check the second directory and that the user was authenticated but that [c.a.c.integration.seraph.CrowdAuthenticator] failed to authenticate the same user.

While this may appear contradictory, this happens because the com.atlassian.jira.security.login.SSOSeraphAuthenticator authenticator class is called up on after the com.atlassian.crowd.manager.application.ApplicationServiceGeneric has successfully authenticated the user with the password from the second directory, where the user was found. After this stage the authentication result is passed on to the Seraph application security framework in Jira, which is the part in Jira that is actually granting the user access to the application. Seraph is in this configuration then uses the simpler SSOSeraphAuthenticator class which will only check the Crowd SSO directory configured in the JIRA/atlassian-jira/WEB-INF/classes/crowd.properties file. If the user is then not found in this second check, then the result of this check overrides the previous result from com.atlassian.crowd.manager.application.ApplicationServiceGeneric , i.e. the flow goes like this:

1. 'affecteduser' user attempts to log in
2. The internal Crowd checks the Crowd directory and does not find the user there.
3. The internal Crowd continues to the next directory in the list: the Internal Directory (as expected) It finds the user there.
4. The internal Crowd successfully authenticates the 'affecteduser' user with the given password and passes the result to Seraph (as expected)
5. Seraph then, as it's using SSOSeraphAuthenticator, ignores this and checks for the user in the external SSO Crowd as defined in 'crowd.properites' in Jira.
6. Authentication fails because 'affecteduser' user does not exist in the Crowd directory.


Solution

The com.atlassian.jira.security.login.SSOSeraphAuthenticator authenticator class is quite limited in its scope and considered obsolete. It is no longer in active development. Please consider moving to a more recent SSO solution, such as the Atlassian Jira SSO app or a third-party SSO app.


Documentation:



Last modified on Sep 6, 2024

Was this helpful?

Yes
No
Provide feedback about this article

Related content

  • No related content found
Powered by Confluence and Scroll Viewport.