Re: SameSite cookies and SAML

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

cheers
Dev



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