<!DOCTYPE html>

<html>

<head>

<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">

</head>

<body>

<div style="font-family:sans-serif"><div style="white-space:normal"><p dir="auto">Thanks Brock. I will try to do some testing and see if this approach works for, say, SimpleSAMLphp.</p>

<p dir="auto">Nick</p>

<p dir="auto">On 3 Jul 2019, at 13:25, Brock Allen wrote:</p>

</div>

<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><div id="AE195AF5-B439-4FAE-A867-19462D86141E"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Lucida Console;color: #000000">

                                        The problem being described is that when an external IdP sends tokens to a callback endpoint in a RP/client/SP, the browser workflow starts from the external site (the IdP), crosses the domain boundary with a token, causing the RP/client/SP to issue its own session cookie (with same-site flag), and then as part of that redirects one more time to the ultimate page in the RP/client/SP (now authenticated with the app's session cookie).<div><br></div><div>At some point Safari seemed to make a change, and users were now observing that the app's same-site cookie was not being sent. The assumption was that during the SSO interaction, initiating from cross-site, Safari was not allowing the app to issue the same-site cookie. But in fact, the browser was accepting the cookie, it just wasn't sending it on the final leg of the redirect chain because the redirect/POST sequence was initiated from cross-site (the IdP). If an end user were to just refresh the page in the app, then the cookie would be sent (because the refresh was not a cross-site request). </div><div><br></div><div>So, if the redirect workflow is broken up in the middle on the response from the cross-domain protocol callback with the response being a 200 OK, issuing the cookie, and then using <meta refresh> tag approach to go to the next page, then the browser will send the cookie on that last request since it's the app itself making that last request, thus allowing the same site cookie to be sent thru. </div><div><br></div><div>At least that's my take on what was happening -- I never even tried to read thru any of the browser's source code to see if my understanding was actually evident in the code. <div><br></div><div>So in ASP.NET, the default was to issue same-site cookies and there were doing ok until Safari made some change. This causes Microsoft to change the defaults in their client-side protocol processing libraries to remove the use of same-site cookies. Perhaps other client-side SSO libraries/frameworks are doing something different to manage it. The solution I proposed in the blog post seems to fix it, but allowing the use of same-site cookies. Given that it's working, I presumed that it confirmed what I understood to be happening (from the browser's perspective).</div><div><br></div><div><span style="font-size: 10pt;line-height: 1.5">I don't think any of what I mention has anything to do with third party cookies, but if so then I'm all ears.</span></div><div><div><br></div><div class="mb_sig"><span style="font-size: 10pt">-Brock</span><div><br></div></div><blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">

                        <p style="color: #AAAAAA; margin-top: 10px;">On 7/3/2019 3:07:43 PM, Nick Roy <nroy@internet2.edu> wrote:</p><div style="font-family:Arial,Helvetica,sans-serif">

<div style="font-family:sans-serif"><div style="white-space:normal"><p dir="auto">Here’s the feedback I got on this from Scott Cantor:</p>

<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">That article seems to be confusing the Same Site issue with the general issue of third party cookies, which is not the same thing, though it's related. It has material that does not match my understanding of the behavior Chrome is actually causing.</p>

</blockquote><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">The Shibboleth SP, for example, absolutely uses that flow described, but it doesn't cause a problem in general. It hasn't broken on iOS, and it's not breaking on Chrome in any testing I've seen.</p>

</blockquote><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">If this was the same thing, I think virtually every SSO app would break, but we're not seeing that.</p>

</blockquote><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">— Scott</p>

</blockquote><p dir="auto">On 3 Jul 2019, at 12:04, Nick Roy via Openid-specs-ab wrote:</p>

</div>

<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><div id="EE587ED9-27BA-4090-B5E4-282AA7B04749">

<div style="font-family:sans-serif"><div style="white-space:normal"><p dir="auto">Thanks - I think this is the same issue, I’ll read this in detail.</p>

<p dir="auto">Nick</p>

<p dir="auto">On 3 Jul 2019, at 12:02, Brock Allen wrote:</p>

</div>

<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><div id="3BD53E9F-05CC-4AD9-99E5-F33569DB59BC"><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Lucida Console;color: #000000">

                                        I wrote about this issue (mainly when it was affecting Safari users), and so I'm not sure if it's the exact same issue you're describing for Chrome. I do describe a workaround to how apps can process responses from cross-domain token servers to handle same-site cookies.<div><br></div><div>https://brockallen.com/2019/01/11/same-site-cookies-asp-net-core-and-external-authentication-providers/<br><div><br></div><div class="mb_sig"><span style="font-size: 10pt">-Brock</span><div><br></div></div><blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">

<p style="color: #AAAAAA; margin-top: 10px;">On 7/3/2019 1:56:05 PM, Nick Roy via Openid-specs-ab <openid-specs-ab@lists.openid.net> wrote:<div style="font-family:Arial,Helvetica,sans-serif">Sorry for the cross-post. Is anyone talking to Google about this issue? Any concerns about it affecting OpenID Connect?

<br>

<br>Thanks,

<br>

<br>Nick

<br>

<br>Forwarded message:

<br>

<br>> From: Pieter van der Meulen <pieter.vandermeulen@surfnet.nl>

<br>> To: refeds@lists.refeds.org

<br>> Subject: [refeds] New chrome SameSite policy for session cookies affecting the SAML HTTP-POST binding

<br>> Date: Wed, 26 Jun 2019 12:39:44 +0000

<br>>

<br>> Hi all,

<br>>

> 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.

<br>>

> 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".

<br>>

> 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.

<br>>

> How to test whether a SP is affected?

<br>> 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.

<br>> 4. (optional) share the results

<br>>

> 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.

<br>>

<br>> You can add the SameSite attribute from the web application itself, or on the web server or load balancer:

<br>> - Apache 2: Header always edit Set-Cookie (.*) "$1; SameSite=None"

<br>> - Nginx: proxy_cookie_path ~(/*) "/$1; SameSite=None";

<br>> - HAProxy: rspirep ^(set-cookie:.*)  \1;\ SameSite=None

<br>>

<br>> Another, more involved, fix is not relying on cookies for the SAML HTTP-POST binding by:

<br>> - setting the session ID in the ID element of the AuthnRequest, or

<br>> - setting the session ID in the RelayState parameter

<br>>

<br>> An (incomplete) list of SP software that is affected:

<br>> - SimpleSAMLphp

<br>> - Shibboleth, depending on the configuration

<br>> - SATOSA [5]

<br>>

<br>> Notes:

<br>> - If you use cookie based load balancing, your LB cookie is affected as well

<br>> - Setting the SameSite attribute is supported since PHP 7.3.0 [6]

<br>>

<br>> Kind regards,

<br>>

<br>> Pieter.

<br>>

<br>>

<br>> [1] https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html

<br>> [2] https://web.dev/samesite-cookies-explained/

<br>> [3] https://tools.ietf.org/html/draft-west-cookie-incrementalism-00

<br>> [4] https://bugs.webkit.org/show_bug.cgi?id=198181

<br>> [5] https://github.com/IdentityPython/SATOSA/issues/245

<br>> [6] https://www.php.net/manual/en/session.configuration.php

<br>>

<br>> --

<br>> Pieter van der Meulen (Pieter.vanderMeulen@surfnet.nl)

<br>> SURFnet (Trust & Security) - www.surfnet.nl

<br>_______________________________________________

<br>Openid-specs-ab mailing list

<br>Openid-specs-ab@lists.openid.net

<br>http://lists.openid.net/mailman/listinfo/openid-specs-ab

<br></pieter.vandermeulen@surfnet.nl></div></blockquote>

                                        </div></div></div></blockquote>

<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px">

</blockquote></div>

</div></div></blockquote>

<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px">

</blockquote><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">_______________________________________________<br>

Openid-specs-ab mailing list<br>

Openid-specs-ab@lists.openid.net<br>

<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" style="color:#777">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></p>

</blockquote></div>

</div>

</div></blockquote>

                                        </div></div></div></div></blockquote>

<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px">

</blockquote></div>

</div>

</body>

</html>