Improve Single-Sign-On Redirect for SameSite=Lax and SameSite=Strict

Lax + POST mitigation as well as the following Spring Security tickets:

• https://github.com/spring-projects/spring-security/issues/14013
• https://github.com/spring-projects/spring-security/issues/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 as SameSite=None pre-login and as SameSite=Strict post-login (Boot-specific solution)

• Have the session cookie always be SameSite=None and introduce a SameSite=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 the RelayState. 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.

Start with the Chromium SameSite FAQ and the linked Spring Security issues 14013 and 11468 to understand the SSO redirect constraints. Compare the four approaches listed here; the work is not ready to start until one approach and its affected entry points and tests are selected, with completion defined by correct same-site behavior for the supported SSO flow.