[Openid-specs-ab] Fwd: [refeds] New chrome SameSite policy for session cookies affecting the SAML HTTP-POST binding
nroy at internet2.edu
Wed Jul 3 17:55:58 UTC 2019
Sorry for the cross-post. Is anyone talking to Google about this issue? Any concerns about it affecting OpenID Connect?
> From: Pieter van der Meulen <pieter.vandermeulen at surfnet.nl>
> To: refeds at lists.refeds.org
> Subject: [refeds] New chrome SameSite policy for session cookies affecting the SAML HTTP-POST binding
> Date: Wed, 26 Jun 2019 12:39:44 +0000
> Hi all,
> Chrome announced plans  to change how cookies work that for several common SP implementations will break SAML authentication using the SAML2int profile. The change in Chrome involves changing the default of the "SameSite" cookie attribute to "Lax" as explained in  and . Because the "SameSite" cookie attribute is a recent addition, most web applications do not set this attribute and thus use the default. Changing the default to "Lax" means that Chrome will not send the cookies that it previously received when the HTTP Request is a cross-site HTTP POST. Such a cross-site HTTP POST is exactly what happens when an IdP uses the SAML HTTP-POST binding so send a SAML Response to a SP. This means that a SP that requires a (session) cookie when receiving the SAML Response on it'a ACS Location using the HTTP-POST binding will break.
> A similar issue exists in OpenID Connect for RPs that use the form_post response mode and that require a (session) cookie. These are typically RPs using Microsoft OpenID Connect libraries. Other OpenID Connect implementations use HTTP GET exclusively, which is allowed cross-domain by "SameSite=Lax".
> We have been discussing this internally at SURFnet and several people from the closed fog list contributed to the discussions. Because this could affect many SPs, and would require changes at those SPs, we concluded that this deserves wider attention, hence this post.
> How to test whether a SP is affected?
> 1. Download the Chrome 76 beta (https://www.google.com/chrome/beta/)
> 2. Open "chrome://flags/" and set the experimental "SameSite by default cookies" flag to "Enabled".
> 3. Login to the SP you want to test.
> 4. (optional) share the results
> The obvious fix is adding a "SameSite=None" attribute to the Set-cookie HTTP header in the HTTP Response. This reenables the old cookie behaviour in Chrome and should not affect other browsers. Unfortunately "SameSite=None" currently breaks Safari browsers , complicating rolling out this fix now.
> You can add the SameSite attribute from the web application itself, or on the web server or load balancer:
> - Apache 2: Header always edit Set-Cookie (.*) "$1; SameSite=None"
> - Nginx: proxy_cookie_path ~(/*) "/$1; SameSite=None";
> - HAProxy: rspirep ^(set-cookie:.*) \1;\ SameSite=None
> Another, more involved, fix is not relying on cookies for the SAML HTTP-POST binding by:
> - setting the session ID in the ID element of the AuthnRequest, or
> - setting the session ID in the RelayState parameter
> An (incomplete) list of SP software that is affected:
> - SimpleSAMLphp
> - Shibboleth, depending on the configuration
> - SATOSA 
> - If you use cookie based load balancing, your LB cookie is affected as well
> - Setting the SameSite attribute is supported since PHP 7.3.0 
> Kind regards,
>  https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html
>  https://web.dev/samesite-cookies-explained/
>  https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
>  https://bugs.webkit.org/show_bug.cgi?id=198181
>  https://github.com/IdentityPython/SATOSA/issues/245
>  https://www.php.net/manual/en/session.configuration.php
> Pieter van der Meulen (Pieter.vanderMeulen at surfnet.nl)
> SURFnet (Trust & Security) - www.surfnet.nl
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 512 bytes
Desc: OpenPGP digital signature
More information about the Openid-specs-ab