Skip to content

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

Open
jzheaux opened this issue Dec 13, 2023 · 3 comments
Open

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

jzheaux opened this issue Dec 13, 2023 · 3 comments
Labels
in: web An issue in web modules (web, webmvc) type: enhancement A general enhancement

Comments

@jzheaux
Copy link
Contributor

jzheaux commented Dec 13, 2023

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

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.

@jzheaux
Copy link
Contributor Author

jzheaux commented Dec 13, 2023

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");
}

@skshitiz-vmw
Copy link

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.
image

@VivionLin
Copy link

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
in: web An issue in web modules (web, webmvc) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

3 participants