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

Tom Jones thomasclinganjones at gmail.com
Thu Jul 4 16:39:14 UTC 2019


see below -  that change has been delayed till 80. Does anyone really think
that Google Authentication will be disabled by Chrome?
What exactly is the problem that people actually see - other than the
safari issues.
Peace ..tom


Lily Chen <chlily at chromium.org>
Tue, Jun 25, 8:28 AM (9 days ago)
to Yoav, Rick, Philip, Lily, Rowan, blink-dev, morlovich, Mike, Brandon
We are pushing back the target milestone to M80 due to interoperability
concerns resulting from an issue affecting Safari on Mac/iOS and Chrome on
iOS <https://bugs.webkit.org/show_bug.cgi?id=198181>: Cookies with an
unrecognized SameSite value, including SameSite=None, are handled
incorrectly and are treated as SameSite=Strict. We decided not to rename
SameSite=None to a different attribute because the issue is fixed in iOS 13
and we think that delaying while the fix rolls out is a better approach
than the longer adoption time for a new attribute.

The console messages informing developers of the changes have been
implemented behind a default-disabled flag and currently do not state a
specific milestone.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE24OxwEX46xH1oO35o6WwSVBF1NDma-Jb2RkjWmgGDFySfE%3Dg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE24OxwEX46xH1oO35o6WwSVBF1NDma-Jb2RkjWmgGDFySfE%3Dg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.


On Wed, Jul 3, 2019 at 8:40 PM Nat Sakimura via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Do we need a spec level change as errata or something?
> Perhaps we need to include SameSite=none as the requirement in the specs?
>
> Nat Sakimura Chairman, OpenID Foundation https://nat.sakimura.org
> 2019年7月4日 5:10 +0900、Filip Skokan via Openid-specs-ab <
> openid-specs-ab at lists.openid.net>のメール:
>
> 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
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
> _______________________________________________
> 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/20190704/51565ed9/attachment-0001.html>


More information about the Openid-specs-ab mailing list