Spring Security SAML fails in Chrome because of favicon request

[mraible]

Describe the bug

I created a simple example with Spring Boot 3 + SAML. In doing so, I discovered that authentication with Chrome failed more often than it succeeded. When it fails, the error message is as follows:

To Reproduce

Clone the following repo and run the app.

https://github.com/mraible/okta-spring-boot-saml-example

Please contact me via Twitter DM if you need credentials.

Expected behavior

I would expect to be able to log in with Chrome or Firefox. Currently, it works all the time in Firefox and every-so-often in Chrome.

Workaround

If I allow all requests to /favicon.ico, it solves the problem. See mraible/okta-spring-boot-saml-example#4 for the code.

[rwinch]

A fix we should consider is to add a RequestMatcher to the HttpSessionSaml2AuthenticationRequestRepository that determines if we should safe the request or not. It would by default ignore the favicon.ico There is president for this given the fact that RequestCacheConfigurer configures the HttpSessionRequestCache to use the same approach.

Alternatively, we could consider avoiding generating a new SAML Request if one exists already. However, the problem with this approach is that it could lead to session fixation style attacks.

[jzheaux]

The authentication request is saved after redirecting from /favicon.ico to /saml2/authenticate/okta, so I'm not sure if we can match the request in the same way as RequestCacheConfigurer does. I'll experiment to see if there's a way to know what the original request was before the redirect.