Summary

The HttpSessionSaml2AuthenticationRequestRepository saves the Saml2AuthenticationRequest in the session and tries to load it after the IdP authenticated the user.

This does not work when using Spring Session because the session cookie is not sent to the server after the IdP authenticated the user.

Spring Session creates a session cookie with SameSite=Lax which causes the browser not to send the cookie when sending the POST request after the IdP authentication.

To Reproduce

Create a minimal Spring Boot application with Spring Security SAML and Spring Session active.

Expected behaviour

After login at the IdP and being redirected to the application the user should be signed in and seeing the secured URL.

Actual behaviour

A new session is created and the user is at the login page again. When he tries to load the secured URL he is able to request it.

Comment From: eleftherias

Thanks for reaching out @tompson.

Note that we have a workaround shared in https://github.com/spring-projects/spring-session/issues/1577.

We will need to think about what changes in Spring Security or Spring Session could make this scenario work, since there is no clear solution at the moment. Feel free to share any suggestions.

Comment From: jzheaux

@tompson, can you clarify how this is an issue with Saml2AuthenticationRequestRepository? It sounds like it's an issue with the RequestCache.

Saml2AuthenticationRequestRepository stores the AuthnRequest for the purpose of validating the InResponseTo value in the SAML 2.0 Response, but such validation has not yet been added.

Comment From: tompson

@eleftherias thanks for that hint, I experimented with different settings for SameSite myself but it is not an option for us to reduce protection against CSRF

@jzheaux I stumbled across this when trying to solve https://github.com/spring-projects/spring-security/issues/10550 and I realised later that it is just an optional validation of InResponseTo - so it is no blocker for us

Comment From: jzheaux

Thanks, @tompson. I wonder if you could create an implementation of RequestCache that keys the saved requests by the AuthnRequest#ID instead of by the session id.

Since there is no problem with Saml2AuthenticationRequestRepository, I'm going to decline this ticket. Feel free to continue the conversation, though, as needed.

Comment From: onmishkin

Thanks, @tompson. I wonder if you could create an implementation of RequestCache that keys the saved requests by the AuthnRequest#ID instead of by the session id.

@jzheaux: Can you connect the dots for me a bit on this? Is the premise that one would write one's own implementation of Saml2AuthenticationRequestRepository that in turn used such an implementation of RequestCache? If so, I'm not seeing how that Saml2AuthenticationRequestRepository implementation's loadAuthenticationRequest(HttpServletRequest) implementation would work without duplicating a bunch of code that's in Saml2AuthenticationTokenConverter to parse the SAML response and then pull out its AuthnRequest#ID.