Describe the bug This is a bug related to SAML2 InResponseTo validation, and I have tested Firefox, Safari, this bug or strange behavior only happens in Chrome. I am not sure if you could say it is a Spring Security bug, but I feel this is the best place to report this. Please let me know otherwise.

So when Chrome doesn't have the favicon cached for the Relying Party's domain, it will request the favicon following the first request. If the first request to the Relying Party and the favicon request are both protected by Spring Security, Chrome will send the SAMLRequest to the Asserting Party based on the first request. But before the browser redirect to the Asserting Party, Spring Security cached the SAMLRequest for the favicon request. When the browser post the SAMLResponse back to Spring Security for validation, it uses the SAMLResponse based on the first SAMLRequest, but Spring Security is checking it against the favicon request SAMLRequest, so the InReponseTo validation failed.

To Reproduce

  1. You will need a local SAML 2 IdP you have access to, let's call it local-saml-idp for the following steps.
  2. Download this 5.7.x saml2 login-single-tenant sample from GitHub spring-security-samples
  3. Change the RelyingPartyRegistration in SecurityConfiguration.java to point to your local-saml-idp metadata.
  4. Edit your host file, add 127.0.0.1 saml-example.com to your host file. Make sure your browser doesn't have any cache for that customized domain.
  5. Register both http://localhost:8080/saml2/service-provider-metadata/two and http://saml-example.com:8080/saml2/service-provider-metadata/two 2 service providers (relying parties) to your local-saml-idp
  6. Start the relying party app.
  7. Login to the local-saml-idp in Chrome.
  8. Access http://localhost:8080, you should be able to login.
  9. Access http://saml-example.com:8080, you will see the InResponseTo not matching login error.

Expected behavior We will expect step 9 should be able to successfully login the app on http://saml-example.com:8080

Sample Sorry I don't have a Sample for this, because it depends on a working IdP, and the host settings.

Other thoughts Currently I have a way to bypass this: 1. Add antMatchers("/favicon.ico").permitAll() to the http security configuration, restart the app. 2. Both http://localhost:8080 and http://saml-example.com:8080 will be able to log in sucessfully.

I am not sure what the solution for this issue will be, but I thought at least I should share what I found just in case if other people are facing the same struggle.

Cheers.

Comment From: marcusdacoregio

Hi @liuyocean, thanks for the report.

This issue has already been fixed here and will be available in Spring Security 5.8. You can try it out by using the milestone releases.

I'll close this as duplicate but feel free to continue the discussion if your scenario is different.

Comment From: liuyocean

@marcusdacoregio, thank you for your information! Next time, I should try searching different keywords to find the issue 😂. Anyway, thank you guys for working on this awesome project!