-
Notifications
You must be signed in to change notification settings - Fork 6k
Improve Single-Sign-On Redirect for SameSite=Lax and SameSite=Strict #14297
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
Comments
Boot applications can achieve the first bullet by doing: private static final String NAME = Authentication.class.getName();
@EventListener
public void onAuthenticationSuccess(AuthenticationSuccessEvent event) {
RequestAttributes attributes = RequestContextHolder.currentRequestAttributes();
attributes.setAttribute(NAME, event.getAuthentication(), RequestAttributes.SCOPE_REQUEST);
}
@Bean
public CookieSameSiteSupplier authenticationBased() {
CookieSameSiteSupplier supplier = (cookie) -> {
RequestAttributes attributes = RequestContextHolder.currentRequestAttributes();
Authentication authentication = (Authentication) attributes.getAttribute(NAME, RequestAttributes.SCOPE_REQUEST);
return (authentication == null || !authentication.isAuthenticated()) ?
Cookie.SameSite.NONE : Cookie.SameSite.STRICT;
};
return supplier.whenHasName("JSESSIONID");
} |
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Lax + POST mitigation as well as the following Spring Security tickets:
explain some of the difficulties around using
SameSite=Lax
orSameSite=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.
The text was updated successfully, but these errors were encountered: