W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2016

Re: SameSite cookies and SAML

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Sat, 18 Jun 2016 21:49:53 -0700
Message-ID: <CAPfop_1HsBEgEzqiH5HrFiUbcArLF7VJb+ia=dO9SDArvbpqMA@mail.gmail.com>
To: Brad Hill <hillbrad@gmail.com>
Cc: Reed Loden <reed@reedloden.com>, security-dev <security-dev@chromium.org>, WebAppSec WG <public-webappsec@w3.org>
> So you shouldn't expect to be able to use SAML in this way with a SameSite
> cookie.   What you can do is represent sessions using two cookies: one
> SameSite and one not.  Check the SameSite cookie only for actions that
> should never be called from off-site.
+1. We are also using a similar approach (although, we are still slowly
rolling it out). A separate cookie has the additional advantage of making
it a lot easier to use strict mode instead of lax.


> On Fri, Jun 17, 2016 at 6:00 AM Reed Loden <reed@reedloden.com> wrote:
>> Greetings,
>> I recently added SameSite=Strict to a site's session cookies, but it was
>> discovered that this breaks SAML authentication (via HTTP POST), as the
>> user's session cookie isn't sent back to the site as part of the SAML
>> authentication response, causing a new session cookie to be generated,
>> which means the user never logged-in. This was mentioned in a recent HN
>> thread as well -- https://news.ycombinator.com/item?id=11787558.
>> For sites that implement SameSite cookies and also allow for
>> authentication via SAML, are there any recommendations on what can be done?
>> SAML also supports HTTP Redirect (GET), but that runs into CSP issues with
>> `frame-src`/`child-src`.
>> One thing that may be possible would be to regenerate the cookie solely
>> based on what the SAML response has in it, but that's not optimal, as you
>> lose any type of state from the previous session (such as a redirect URL to
>> use once the user is logged-in).
>> Any thoughts people might have on finding a way to support SAML
>> authentication with SameSite cookies are welcome! :-)
>> ~reed
> --
> You received this message because you are subscribed to the Google Groups
> "Security-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to security-dev+unsubscribe@chromium.org.
Received on Sunday, 19 June 2016 04:50:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:56 UTC