Summary

Intermittent "InResponseTo" SAML errors encountered when session goes idle and needs to re-authenticate through Azure SSO.
If users let their session go idle, when the browser starts navigating again the session needs to be re-auth'd but this can randomly result in a "InResponseTo" SAML error where the InResponseTo attribute was sent but it wasn't expected. This can also happen if a race condition is made by being not authenticated and then opening multiple browser tabs which load a Confluence page each all at the same time. 

Environment

Single Sign On (SSO 2.0) configured to use Azure SSO solution (login.microsoftonline.com)

• Confluence 7.4.0 
• "SAML for Atlassian Data Center" or SSO for Atlassian Server and Data Center plugin versions before 3.2.5, 4.0.8, 4.1.5

Reproducing the Issue

The following sequence of events leads to being presented with the InResponseTo was not expected error:

1. You're logged out for whatever reason (intentionally logged out or timed out)
2. You then click a link to a Confluence page
3. This initiates a SSO log in and puts your authentication request id in the session
4. Something then happens to that session (it expires, it's overwritten due to concurrent requests forcing a new session id, you delete your cookies)
5. This leads to you completing your SSO login but you no longer have the same session ID which has the authentication request ID, meaning the response was to a request the authentication does not know of.

A way to recreate this on-demand is to intentionally make concurrent requests by creating a bookmark folder with 7 to 10 links to Confluence pages, login once to Confluence to cache the login.microsoftonline.com SSO cookie, then logout of Confluence and attempt to open all bookmarks in that folder at once (right click, open all). This will result in some succeeding and some failing if you run this experiment over and over.  

Diagnosis

Add the following to your setenv.sh file and restart Confluence:

CATALINA_OPTS="-Datlassian.darkfeature.atlassian.authentication.include.stacktrace.in.error.messages=true ${CATALINA_OPTS}"

This will allow you to see the stack trace of the error message you receive in the UI, confirm it similar to the below. You can also search the atlassian-confluence.log for "InResponseTo" if you do not wish to add the above system property.

com.atlassian.plugins.authentication.impl.web.saml.provider.InvalidSamlResponse: Received invalid SAML response: The Response has an InResponseTo attribute: ONELOGIN_1a4d31b4-5cb6-494a-85b1-f7eed57991dc while no InResponseTo was expected
	at com.atlassian.plugins.authentication.impl.web.saml.provider.impl.OneloginJavaSamlProvider.lambda$extractSamlResponse$1(OneloginJavaSamlProvider.java:89)
	at com.atlassian.plugin.util.ContextClassLoaderSwitchingUtil.runInContext(ContextClassLoaderSwitchingUtil.java:48)
	at com.atlassian.plugins.authentication.impl.web.saml.provider.impl.OneloginJavaSamlProvider.extractSamlResponse(OneloginJavaSamlProvider.java:80)
	at com.atlassian.plugins.authentication.impl.web.saml.SamlConsumerServlet.doPost(SamlConsumerServlet.java:87)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:660)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
	at com.atlassian.plugin.servlet.DelegatingPluginServlet.service(DelegatingPluginServlet.java:37)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
	at com.atlassian.plugin.servlet.ServletModuleContainerServlet.service(ServletModuleContainerServlet.java:46)
	at com.atlassian.confluence.servlet.ServletModuleContainerServlet.service(ServletModuleContainerServlet.java:47)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
...truncated...

Capture a HAR while reproducing the issue

1. Use Google Chrome to access Confluence.
2. Open the Chrome developer toolbar (Right click on any empty space of chrome window, choose Inspect Element or see another way of opening the tool at this page).
3. Go to the Network tab (see example here). Clear all the existing text in the Network tab if there's any by clicking the remove icon next to the red circle icon at top right corner of the developer tool window.
4. Reproduce the issue
5. There will be HTTP requests logged into the network window - save this information to a HAR file (instructions for this)

Cause

From analyzing the HAR your will see that the SAML request is going out while JSESSIONID #1 is being used in the cookie, but the SAML response comes back when the JSESSIONID is now using value #2 and this is why the error states that "no InResponseTo was expected", because it was not expected by JESSIONID #2, it was expected by JESSIONID #1.

Further analysis of the HAR shows it cycling between JSESSIONIDs frequently each time it re-authenticates to the Azure SSO IdP. 

Solution

Upgrade the SSO plugin.

Since this plugin is used by multiple products (Jira, Confluence, Bitbucket, etc.), install / upgrade the SSO for Atlassian Server and Data Center plugin to version 3.2.5/4.0.8/4.1.5 or higher depending on what version of the plugin your Atlassian product supports.

Alternate cause and solution

This can also be due the value of the SameSite attribute in the cookie, please see SSO triggers error "Received invalid SAML response" when attempting to log into Confluence using Google Chrome for more information.