SameSite attribute break SAML flow

Question

Chrome 80 will introduce a new attribute which is SameSite.

• Strict - Only attach cookies for ‘same-site’ requests.
• Lax - Send cookies for ‘same-site’ requests, along with ‘cross-site’ top level navigations using safe HTTP methods e.g. (GET HEAD OPTIONS TRACE).
• None - send cookies for all ‘same-site’ and ‘cross-site’ requests.

For more information, this article explains SameSite pretty good.

From Azure documentation:

The cloud service (the service provider) uses an HTTP Redirect binding to pass an AuthnRequest (authentication request) element to Azure AD (the identity provider). Azure AD then uses an HTTP post binding to post a Response element to the cloud service

My question is why SameSite breaks SAML flow? 🔍"saml" samesite problem

When IdP POST response back to SP, if SameSite=Lax, user-agent will not send cookies that has SP domain. Even if it does not send cookies I don't see there is any problem with SP.

Reitareiter

Answer 1

When IdP POST response back to SP, if SameSite=Lax, user-agent will not send cookies that has SP domain. Even if it does not send cookies I don't see there is any problem with SP.

On IdP-init, there likely wouldn't be any issues whatsoever, because there's no state outside of the SAML Response that is sent.

SP-init flows, however, would very likely be broken. The reason is that most SP products track the browser session via a cookie that it sets before sending the user to the IdP. The browser is redirected to the IdP, authenticated, and sent back to the SP with the response on a POST. If the cookie wasn't set with SameSite=None;Secure (don't forget - cookies that need SameSite=None also have to be set with Secure), then the SP's cookie won't be passed back to the SP with the POST, making it so the SP doesn't have all the pieces it needs to configure the session securely.

One way to look at it would be like the user needs two sets of keys to establish a secure session at the SP: The first is that it wants its session key from the cookie, and the other is that it wants the key from the IdP.

Bubalo

Answer 2

>> Even if it does not send cookies I don't see there is any problem with SP.

If the IdP cookie is not properly set with SameSite=None, it will not be sent on the request from SP to the IdP, and the user will be asked to log in to the IdP again.

Source : https://support.okta.com/help/s/article/FAQ-How-Chrome-80-Update-for-SameSite-by-default-Potentially-Impacts-Your-Okta-Environment

Thats what is done by Shibboleth IDP : https://issues.shibboleth.net/jira/browse/IDP-1476

Rounder

Thanks for your resources. Hmm, you mean SP sends AuthnRequest to IdP right. That's true if SP use POST Binding, if SP uses Redirect Binding it's no problem. – Reitareiter

Btw why choose POST over Redirect Binding? Hmm, is that because the capacity POST message can have? – Reitareiter

One should never use Redirect for presenting an assertion back to the SP, it's a huge data leak issue, because anything that has the full URL (like various logs scattered about the various ingress/egress points, etc.) have all the information about the assertion. – Bubalo

Answer 3

With Lax, browser will pass the cookies with cross-site requests only through top-level navigation (GET). So cookies will not be passed along with cross-site requests which was made through HttpMethods other than GET (like POST). You can find More information here : https://thilankadeshan.wordpress.com/2020/11/09/jsession-new-samesite-cookie-policy-in-google-chrome-and-spring/

Bobker