[Openid-specs-ab] Fwd: [refeds] New chrome SameSite policy for session cookies affecting the SAML HTTP-POST binding
panva.ip at gmail.com
Wed Jul 3 18:50:36 UTC 2019
I summarized the effects in this thread
On Wed, 3 Jul 2019 at 19:56, Nick Roy via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:
> Sorry for the cross-post. Is anyone talking to Google about this issue?
> Any concerns about it affecting OpenID Connect?
> Forwarded message:
> > 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
> > 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 
> > Notes:
> > - If you use cookie based load balancing, your LB cookie is affected as
> > - Setting the SameSite attribute is supported since PHP 7.3.0 
> > Kind regards,
> > Pieter.
> > 
> >  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
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab