Description
Lax + POST mitigation as well as the following Spring Security tickets:
- Change the default implementation of Saml2AuthenticationRequestRepository to store and load AuthnRequests based on the ID instead of the session #14013
- Receive AuthnRequest Id and Response InResponseTo in Saml2AuthenticationRequestRepository #11468
explain some of the difficulties around using SameSite=Lax
or SameSite=Strict
when using SSO technologies like SAML and others that redirect with a POST.
There are a few ways to consider:
-
Provide an implementation of
CookieSameSiteSupplier
that writes the session cookie asSameSite=None
pre-login and asSameSite=Strict
post-login (Boot-specific solution) -
Have the session cookie always be
SameSite=None
and introduce aSameSite=Strict
correlation cookie when authentication succeeds. The correlation cookie has a secure random value that must match a certain session attribute, lest the session be invalidated. -
Add a separate
SameSite=None
cookie whose opaque token references pre-login information, the opaque token could be theRelayState
. It would be created when login begins and destroyed when login completes either successfully or unsuccessfully. -
Use the Artifact binding instead (SAML-specific). Such allows the redirect from the IdP to be a GET instead of a POST.
Activity
jzheaux commentedon Dec 13, 2023
Boot applications can achieve the first bullet by doing:
skshitiz-vmw commentedon Jan 8, 2024
To add one scenario related to the first bullet:

if we try to set Cookie.SameSite as none in http application (not https secure), we will get ERR_TOO_MANY_REDIRECTS as the application will redirect too many times because Cookie.Secure = true won't work until the application uses https, not http.
VivionLin commentedon Jul 11, 2024
My project is using 3.2.5. The CookieSameSiteSupplier not work for me because Saml2WebSsoAuthenticationRequestFilter finally uses CookieHttpSessionIdResolver and then DefaultCookieSerializer to write the session cookie.