[Openid-specs-ab] Fwd: [refeds] New chrome SameSite policy for session cookies affecting the SAML HTTP-POST binding

Filip Skokan panva.ip at gmail.com
Wed Jul 3 18:50:36 UTC 2019


Hi Nick,

I summarized the effects in this thread
<http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20190527/007341.html>
.

S pozdravem,
*Filip Skokan*


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?
>
> Thanks,
>
> Nick
>
> 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 [1] 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 [2] and [3]. 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 [4], 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 [5]
> >
> > Notes:
> > - 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 [6]
> >
> > Kind regards,
> >
> > Pieter.
> >
> >
> > [1]
> https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html
> > [2] https://web.dev/samesite-cookies-explained/
> > [3] https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
> > [4] https://bugs.webkit.org/show_bug.cgi?id=198181
> > [5] https://github.com/IdentityPython/SATOSA/issues/245
> > [6] 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
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190703/8ebd3356/attachment.html>


More information about the Openid-specs-ab mailing list