Uploaded image for project: 'Crowd Data Center'
  1. Crowd Data Center
  2. CWD-2814

Unable to login to JIRA/Confluence with a Crowd login which is aliased

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Medium Medium
    • 2.6.2
    • 2.6
    • None

      This might better belong in JIRA but as it affects both JIRA and Confluence I suspect it may be related to Crowd implementation in these products.

      If you create the following user setup:

      • Crowd - brendan.haire@atlassian.com
      • JIRA - bhaire2

      Then you enable SSO and hook up Crowd and JIRA and alias brendan.haire@atlassian to be bhaire2 in JIRA you are able to login to Crowd and then have SSO across to JIRA.

      However, if you attempt to login to JIRA with brendan.haire@atlassian.com (rather than the actual user name bhaire2) you are presented with the following error (see attached "Screen Shot 2012-04-13 at 4.06.14 PM.png"):

      2012-04-13 14:14:29,408 http-8080-5 ERROR [500ErrorPage.jsp] Exception caught in 500 page user should not be null!
      com.atlassian.jira.util.dbc.Assertions$NullArgumentException: user should not be null!
      at com.atlassian.jira.util.dbc.Assertions.notNull(Assertions.java:28)
      at com.atlassian.jira.security.login.LoginManagerImpl.authorise(LoginManagerImpl.java:140)
      at com.atlassian.jira.security.JiraRoleMapper.canLogin(JiraRoleMapper.java:46)
      at com.atlassian.seraph.auth.DefaultAuthenticator.isAuthorised(DefaultAuthenticator.java:229)
      at com.atlassian.seraph.auth.DefaultAuthenticator.authoriseUserAndEstablishSession(DefaultAuthenticator.java:197)
      at com.atlassian.seraph.auth.DefaultAuthenticator.login(DefaultAuthenticator.java:102)
      at com.atlassian.crowd.integration.seraph.v25.CrowdAuthenticator.login(CrowdAuthenticator.java:135)
      at com.atlassian.seraph.filter.PasswordBasedLoginFilter.runAuthentication(PasswordBasedLoginFilter.java:127)
      at com.atlassian.seraph.filter.PasswordBasedLoginFilter.login(PasswordBasedLoginFilter.java:72)
      at com.atlassian.seraph.filter.BaseLoginFilter.doFilter(BaseLoginFilter.java:130)
      at com.atlassian.jira.web.filters.JiraLoginFilter.doFilter(JiraLoginFilter.java:70)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:46)
      at com.atlassian.plugin.servlet.filter.DelegatingPluginFilter$1.doFilter(DelegatingPluginFilter.java:66)
      at com.atlassian.oauth.serviceprovider.internal.servlet.OAuthFilter.doFilter(OAuthFilter.java:71)
      at com.atlassian.plugin.servlet.filter.DelegatingPluginFilter.doFilter(DelegatingPluginFilter.java:74)
      at com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:42)
      at com.atlassian.plugin.servlet.filter.DelegatingPluginFilter$1.doFilter(DelegatingPluginFilter.java:66)
      at com.atlassian.plugins.rest.module.servlet.RestSeraphFilter.doFilter(RestSeraphFilter.java:40)
      at com.atlassian.plugin.servlet.filter.DelegatingPluginFilter.doFilter(DelegatingPluginFilter.java:74)
      at com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:42)
      at com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:77)
      at com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:63)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at com.atlassian.johnson.filters.AbstractJohnsonFilter.doFilter(AbstractJohnsonFilter.java:71)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:350)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at com.atlassian.gzipfilter.GzipFilter.doFilterInternal(GzipFilter.java:81)
      at com.atlassian.gzipfilter.GzipFilter.doFilter(GzipFilter.java:51)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:46)
      at com.atlassian.plugin.servlet.filter.DelegatingPluginFilter$1.doFilter(DelegatingPluginFilter.java:66)
      at com.sysbliss.jira.plugins.workflow.servlet.JWDSendRedirectFilter.doFilter(JWDSendRedirectFilter.java:25)
      at com.atlassian.plugin.servlet.filter.DelegatingPluginFilter.doFilter(DelegatingPluginFilter.java:74)
      at com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:42)
      at com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:77)
      at com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:63)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at com.atlassian.jira.web.filters.steps.ChainedFilterStepRunner.doFilter(ChainedFilterStepRunner.java:78)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at com.atlassian.core.filters.cache.AbstractCachingFilter.doFilter(AbstractCachingFilter.java:33)
      at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:31)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at com.atlassian.core.filters.encoding.AbstractEncodingFilter.doFilter(AbstractEncodingFilter.java:41)
      at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:31)
      at com.atlassian.jira.web.filters.PathMatchingEncodingFilter.doFilter(PathMatchingEncodingFilter.java:45)
      at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:31)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at com.atlassian.jira.web.monitor.ActiveRequestsFilter$PassToChainFilterFunc.doFilter(ActiveRequestsFilter.java:346)
      at com.atlassian.jira.web.monitor.ActiveRequestsFilter$DebugLogFilterFunc.doFilter(ActiveRequestsFilter.java:463)
      at com.atlassian.jira.web.monitor.ActiveRequestsFilter.doFilter(ActiveRequestsFilter.java:173)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at com.atlassian.jira.startup.JiraStartupChecklistFilter.doFilter(JiraStartupChecklistFilter.java:75)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at com.atlassian.multitenant.servlet.MultiTenantServletFilter.doFilter(MultiTenantServletFilter.java:91)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at com.atlassian.jira.web.filters.steps.ChainedFilterStepRunner.doFilter(ChainedFilterStepRunner.java:78)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
      at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
      at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:554)
      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
      at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
      at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
      at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
      at java.lang.Thread.run(Thread.java:680)

            [CWD-2814] Unable to login to JIRA/Confluence with a Crowd login which is aliased

            We have this problem in crowd 2.7.0

            and Jira 6.1.5

            Cuenta Smartsoft added a comment - We have this problem in crowd 2.7.0 and Jira 6.1.5

            Crowd 2.6.2 is actually available now.

            http://www.atlassian.com/software/crowd/download

            I had the same issue as this ticket and the upgrade fixed it.

            Alexander Wolden added a comment - Crowd 2.6.2 is actually available now. http://www.atlassian.com/software/crowd/download I had the same issue as this ticket and the upgrade fixed it.

            That's good to know.

            Does the fact that this is a release candidate mean that there might still be the opportunity to stop those error messages?

            I don't suppose there is any information as to when 2.6.2 might become generally available?

            Thanks.

            Philip

            Philip Colmer added a comment - That's good to know. Does the fact that this is a release candidate mean that there might still be the opportunity to stop those error messages? I don't suppose there is any information as to when 2.6.2 might become generally available? Thanks. Philip

            I confirmed that 2.6.2-rc fixes the SSO authentication issue with aliased users with JIRA 5.2.8 and Confluence 5.1.1. Aliased users can now seamlessly log in into JIRA/Confluence. Attempts to log in with the original username may still cause some error messages, but the SSO session is actually created and the user can access the applications.

            Diego Berrueta added a comment - I confirmed that 2.6.2-rc fixes the SSO authentication issue with aliased users with JIRA 5.2.8 and Confluence 5.1.1. Aliased users can now seamlessly log in into JIRA/Confluence. Attempts to log in with the original username may still cause some error messages, but the SSO session is actually created and the user can access the applications.

            I forgot to mention that I did have a support ticket open about this where I've got more detailed logs of what I had tested: https://support.atlassian.com/browse/CWDSUP-7625

            Philip Colmer added a comment - I forgot to mention that I did have a support ticket open about this where I've got more detailed logs of what I had tested: https://support.atlassian.com/browse/CWDSUP-7625

            Diego

            Are you saying that Crowd 2.6.2-rc fixes the problem?

            My research shows that with Crowd 2.6.0 and JIRA 5.2.8:

            • Without aliasing, you can log in as expected with either a local JIRA account or a Crowd account.
            • If you add an alias to the Crowd account and try to log onto JIRA with the unaliased username, login fails. However, if you log into Crowd and then go to JIRA, you have an SSO session and you are in.

            If you disable SSO in JIRA and just use Crowd as another directory, there are still problems in that if you set an alias on a Crowd account, you cannot then log in with the aliased username and if you log in with the unaliased username, the profile in JIRA shows the unaliased name and not the aliased one.

            Thanks.

            Philip Colmer added a comment - Diego Are you saying that Crowd 2.6.2-rc fixes the problem? My research shows that with Crowd 2.6.0 and JIRA 5.2.8: Without aliasing, you can log in as expected with either a local JIRA account or a Crowd account. If you add an alias to the Crowd account and try to log onto JIRA with the unaliased username, login fails. However, if you log into Crowd and then go to JIRA, you have an SSO session and you are in. If you disable SSO in JIRA and just use Crowd as another directory, there are still problems in that if you set an alias on a Crowd account, you cannot then log in with the aliased username and if you log in with the unaliased username, the profile in JIRA shows the unaliased name and not the aliased one. Thanks.

            Same experiment again, using Crowd 2.5.0 and JIRA 5.2.5 configured for SSO.

            Login method (JIRA) Using the alias as username Using the unaliased username as username With unaliased user
            Login gadget Does not log in, but creates a SSO session for 'username' Logs in, redirects to the Dashboard. "The user 'alias' has PASSED authentication" is printed to the security log. It creates a SSO session for 'username' Logs in, creates SSO session
            Login screen (/login.jsp) Does not log in, but creates a SSO session for 'username' Returns to login screen, displays error. "The user 'alias' has PASSED authentication" is printed to the security log. The user is actually logged in, and can navigate to the Dashboard. It creates a SSO session for 'username' Logs in, creates SSO session

            This indicates that the fix for CWD-3219 is actually a fix for a regression introduced in Crowd 2.6.x, and that some other factor has played a role in the actual fix of this issue (CWD-2814) in Crowd 2.6.2-rc.

            Diego Berrueta added a comment - Same experiment again, using Crowd 2.5.0 and JIRA 5.2.5 configured for SSO. Login method (JIRA) Using the alias as username Using the unaliased username as username With unaliased user Login gadget Does not log in, but creates a SSO session for 'username' Logs in, redirects to the Dashboard. "The user 'alias' has PASSED authentication" is printed to the security log. It creates a SSO session for 'username' Logs in, creates SSO session Login screen (/login.jsp) Does not log in, but creates a SSO session for 'username' Returns to login screen, displays error. "The user 'alias' has PASSED authentication" is printed to the security log. The user is actually logged in, and can navigate to the Dashboard. It creates a SSO session for 'username' Logs in, creates SSO session This indicates that the fix for CWD-3219 is actually a fix for a regression introduced in Crowd 2.6.x, and that some other factor has played a role in the actual fix of this issue ( CWD-2814 ) in Crowd 2.6.2-rc.

            Same experiment, using Crowd 2.6.1 and JIRA 5.2.5 configured for SSO.

            Login method (JIRA) Using the alias as username Using the unaliased username as username
            Login gadget Does not log in, but creates a SSO session for 'alias' (wrong!) Does not log in, but creates a SSO session for 'alias' (wrong!)
            Login screen (/login.jsp) Does not log in, but creates a SSO session for 'alias' (wrong!) Does not log in, but creates a SSO session for 'alias' (wrong!)

            To the best of my knowledge, the fix for CWD-3219 has fixed also this issue.

            Diego Berrueta added a comment - Same experiment, using Crowd 2.6.1 and JIRA 5.2.5 configured for SSO. Login method (JIRA) Using the alias as username Using the unaliased username as username Login gadget Does not log in, but creates a SSO session for 'alias' (wrong!) Does not log in, but creates a SSO session for 'alias' (wrong!) Login screen (/login.jsp) Does not log in, but creates a SSO session for 'alias' (wrong!) Does not log in, but creates a SSO session for 'alias' (wrong!) To the best of my knowledge, the fix for CWD-3219 has fixed also this issue.

            This is the behaviour that I observe with Crowd 2.6.2-rc and JIRA 5.2.5 configured for SSO.

            Login method (JIRA) Using the alias as username Using the unaliased username as username
            Login gadget Logs in, creates SSO session, redirects to the Dashboard Logs in, creates SSO session, redirects to the Dashboard
            Login screen (/login.jsp) Logs in, creates SSO session, redirects to the Dashboard Apparently fails to log in into JIRA because it displays an error. Actually, it creates SSO session, and stays in the login screen but you can follow the link to the Dashboard and it works

            When logging in as the unaliased username, the security log shows:

            # Using login gadget
            2013-04-17 15:15:06,034 http-2990-3 anonymous 915x21171x1 owf0wy 0:0:0:0:0:0:0:1 /rest/gadget/1.0/login login : 'user@example.com' tried to login but they do not have USE permission or weren't found. Deleting remember me cookie.
            2013-04-17 15:15:06,052 http-2990-3 anonymous 915x21171x1 owf0wy 0:0:0:0:0:0:0:1 /rest/gadget/1.0/login HttpSession [owf0wy] destroyed for 'anonymous'
            2013-04-17 15:15:06,052 http-2990-3 anonymous 915x21171x1 owf0wy 0:0:0:0:0:0:0:1 /rest/gadget/1.0/login HttpSession created [owf0wy]
            2013-04-17 15:15:06,063 http-2990-3 alias 915x21171x1 owf0wy 0:0:0:0:0:0:0:1 /rest/gadget/1.0/login The user 'alias' has PASSED authentication.
            
            # Using /login.jsp
            2013-04-17 15:12:11,026 http-2990-5 anonymous 912x19448x1 owf0wy 0:0:0:0:0:0:0:1 /login.jsp login : 'user@example.com' tried to login but they do not have USE permission or weren't found. Deleting remember me cookie.
            2013-04-17 15:12:11,044 http-2990-5 anonymous 912x19448x1 owf0wy 0:0:0:0:0:0:0:1 /login.jsp HttpSession [owf0wy] destroyed for 'anonymous'
            2013-04-17 15:12:11,044 http-2990-5 anonymous 912x19448x1 owf0wy 0:0:0:0:0:0:0:1 /login.jsp HttpSession created [owf0wy]
            2013-04-17 15:12:11,055 http-2990-5 alias 912x19448x1 owf0wy 0:0:0:0:0:0:0:1 /login.jsp The user 'alias' has PASSED authentication.
            

            Diego Berrueta added a comment - This is the behaviour that I observe with Crowd 2.6.2-rc and JIRA 5.2.5 configured for SSO . Login method (JIRA) Using the alias as username Using the unaliased username as username Login gadget Logs in, creates SSO session, redirects to the Dashboard Logs in, creates SSO session, redirects to the Dashboard Login screen (/login.jsp) Logs in, creates SSO session, redirects to the Dashboard Apparently fails to log in into JIRA because it displays an error. Actually, it creates SSO session, and stays in the login screen but you can follow the link to the Dashboard and it works When logging in as the unaliased username, the security log shows: # Using login gadget 2013-04-17 15:15:06,034 http-2990-3 anonymous 915x21171x1 owf0wy 0:0:0:0:0:0:0:1 /rest/gadget/1.0/login login : 'user@example.com' tried to login but they do not have USE permission or weren't found. Deleting remember me cookie. 2013-04-17 15:15:06,052 http-2990-3 anonymous 915x21171x1 owf0wy 0:0:0:0:0:0:0:1 /rest/gadget/1.0/login HttpSession [owf0wy] destroyed for 'anonymous' 2013-04-17 15:15:06,052 http-2990-3 anonymous 915x21171x1 owf0wy 0:0:0:0:0:0:0:1 /rest/gadget/1.0/login HttpSession created [owf0wy] 2013-04-17 15:15:06,063 http-2990-3 alias 915x21171x1 owf0wy 0:0:0:0:0:0:0:1 /rest/gadget/1.0/login The user 'alias' has PASSED authentication. # Using /login.jsp 2013-04-17 15:12:11,026 http-2990-5 anonymous 912x19448x1 owf0wy 0:0:0:0:0:0:0:1 /login.jsp login : 'user@example.com' tried to login but they do not have USE permission or weren't found. Deleting remember me cookie. 2013-04-17 15:12:11,044 http-2990-5 anonymous 912x19448x1 owf0wy 0:0:0:0:0:0:0:1 /login.jsp HttpSession [owf0wy] destroyed for 'anonymous' 2013-04-17 15:12:11,044 http-2990-5 anonymous 912x19448x1 owf0wy 0:0:0:0:0:0:0:1 /login.jsp HttpSession created [owf0wy] 2013-04-17 15:12:11,055 http-2990-5 alias 912x19448x1 owf0wy 0:0:0:0:0:0:0:1 /login.jsp The user 'alias' has PASSED authentication.

            This is a complete roadblock to our adoption of Crowd as a centralised user management system with JIRA. We've been using JIRA for quite a few months now and I want to use Crowd instead with an LDAP back-end. Unfortunately, the fact that I cannot alias Crowd accounts onto the existing JIRA accounts means we either have to stick with two separate user bases (yuck) or we don't alias the two accounts together (equal yuck).

            I'm very concerned though that this got raised in April 2012 and nobody has looked at it since!

            Philip Colmer added a comment - This is a complete roadblock to our adoption of Crowd as a centralised user management system with JIRA. We've been using JIRA for quite a few months now and I want to use Crowd instead with an LDAP back-end. Unfortunately, the fact that I cannot alias Crowd accounts onto the existing JIRA accounts means we either have to stick with two separate user bases (yuck) or we don't alias the two accounts together (equal yuck). I'm very concerned though that this got raised in April 2012 and nobody has looked at it since!

              dberrueta Diego Berrueta
              bhaire B
              Affected customers:
              4 This affects my team
              Watchers:
              8 Start watching this issue

                Created:
                Updated:
                Resolved: