Error 401 in our JIRA App while we're actually authenticated

Hi,

We recently updated the tomcat conf of our JIRA App (XStudio) so that it matches the latest security requirements of Atlassian (TLS 1.2 only, HSTS)

Since then (I think), we have a strange issue. When the user click on “Configure” to configure the app and save its changes it gets and text error (in json):

{“error”: 401, “message”: “unauthorized”…}

But I can check in our log that everything is ok and that the authentication is ok.

We checked Atlassian code and the “Verified JWT for host” message (in our log below) is printed only if the JWT is Ok so the authentication is definitely ok.

You can see the log below.

Any idea ? could it be the filter we added to tomcat for HSTS ?

2021-05-27 06:54:03,139 https-jsse-nio-8443-exec-7 TRACE o.s.t.s.TransactionSynchronizationManager doUnbindResource Removed value [org.springframework.data.jpa.repository.support.CrudMethodMetadataPostProcessor$DefaultCrudMethodMetadata@6edffd8] for key [public abstract java.util.Optional org.springframework.data.repository.CrudRepository.findById(java.lang.Object)] from thread [https-jsse-nio-8443-exec-7]
2021-05-27 06:54:03,140 https-jsse-nio-8443-exec-7 DEBUG c.a.c.s.i.a.j.JwtAuthenticationProvider verifyToken **Verified JWT for host** https://xqual-dev.atlassian.net (5eedb5f8-7df6-342a-a050-49eb1d53050a)
2021-05-27 06:54:03,141 https-jsse-nio-8443-exec-7 DEBUG c.a.c.s.i.a.j.JwtAuthenticationProvider computeQueryStringHash Canonical request for incoming JWT: [CanonicalHttpServletRequest@484e2a66 method = 'POST', relativePath = '/configuration', parameterMap = '[requirementIssueTypes -> (Story,Task,Epic),bugIssueTypes -> (Bug,Task,Epic),xstudioBaseUrl -> (https://xqual-dev-eric2.myxqual.com/xqual/plugins/jira),username -> (admin),password -> (password),showInline -> (on),jwt -> (eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhdWQiOiJjb20ueHF1YWwuamlyYS5qaXJhLXhzdHVkaW8tY29ubmVjdC1wbHVnaW4iLCJzdWIiOiI1NTcwNTg6OWIwM2YzNzktNjU5YS00MzAyLTg3MTMtZjE4NDNhZjczOTdjIiwiY2xpZW50S2V5IjoiNWVlZGI1ZjgtN2RmNi0zNDJhLWEwNTAtNDllYjFkNTMwNTBhIiwicXNoIjoiY29udGV4dC1xc2giLCJpc3MiOiJjb20ueHF1YWwuamlyYS5qaXJhLXhzdHVkaW8tY29ubmVjdC1wbHVnaW4iLCJleHAiOjE2MjIwOTkzMjgsImlhdCI6MTYyMjA5ODQyOH0.L89N3SMlBV2nC9qGsWIHDiNhxW6lznPjonLfKMjnS34),save -> (Save),]']
2021-05-27 06:54:03,149 https-jsse-nio-8443-exec-7 TRACE o.s.web.servlet.DispatcherServlet traceDebug POST "/jira-xstudio-connect-plugin-5/configuration", parameters={masked}, headers={masked} in DispatcherServlet 'dispatcherServlet'
2021-05-27 06:54:03,151 https-jsse-nio-8443-exec-7 TRACE o.s.b.f.s.DefaultListableBeanFactory doGetBean Returning cached instance of singleton bean 'configurationController'
2021-05-27 06:54:03,151 https-jsse-nio-8443-exec-7 TRACE o.s.w.s.m.m.a.RequestMappingHandlerMapping getHandler Mapped to com.xqual.jira.xstudio.configuration.ConfigurationController#save(AddonConfig, AtlassianHostUser, Model)
2021-05-27 06:54:03,151 https-jsse-nio-8443-exec-7 DEBUG o.s.web.servlet.DispatcherServlet logResult **Completed 401 UNAUTHORIZED** , headers={masked}
2021-05-27 06:54:03,152 https-jsse-nio-8443-exec-7 DEBUG o.s.s.w.a.ExceptionTranslationFilter doFilter Chain processed normally
2021-05-27 06:54:03,152 https-jsse-nio-8443-exec-7 DEBUG o.s.s.w.c.SecurityContextPersistenceFilter doFilter SecurityContextHolder now cleared, as request processing completed

Just in case, the filter we added in our App’s tomcat:

<filter>
<filter-name>httpHeaderSecurity</filter-name>
<filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
<async-supported>true</async-supported>
<init-param>
<param-name>hstsEnabled</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>hstsMaxAgeSeconds</param-name>
<param-value>31536000</param-value>
</init-param>
<init-param>
<param-name>hstsIncludeSubDomains</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>antiClickJackingEnabled</param-name>
<param-value>false</param-value>
</init-param>
</filter>
httpHeaderSecurity /* REQUEST

This is the only change we made.

Thanks,

I don’t have an answer directly for your question, but I wanted to call your attention to this topic: Accessing cloud REST api via generated JWT token. It sounds similar and thought it might be worth you reading through to see if anything in there helps unblock you.

Hi @bentley,
thanks for the link, but after reading into it I don’t think this is related to our problem: we do not generate the JWT token ourselves - it’s all handled by ACSB.
In fact, the add-on was working perfectly until we upgraded to ACSB 2.1.5 and applied the changes required by this announcement.
What’s puzzling me, is that the user can access the configuration page, so s/he must be authenticated somehow. It’s only when the POST call to update the configuration is sent that the error occurs.
Any ideas?

Come on guys, nudge, nudge :wink: … really nobody here who can share some thoughts why this problem happens? We’d really be grateful for every hint.