SameSite cookies and SAML

[Reed Loden]

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

[Ricardo Iramar dos Santos]

Just adding another question under the same topic.
What would be the priority between SameSite=Stric cookie and
Access-Control-Allow-Credentials CORS header?

[Brad Hill]

These two things have explicitly opposite design goals.  SAML authentication endpoints expect requests originating from off-site. That's how the protocol works.  That it is possible to make HTTP requests between applications in a fully interoperable way is a great and valuable thing about the web platform.  It's what makes the web a web.  

SameSite cookies are not everywhere and always a good thing.  Very few web applications of any reasonable complexity will be able to move to using SameSite cookies exclusively. They are a good thing for endpoints that shouldn't be invoked from off-site; a property that was previously difficult to enforce on the web platform when you did want it.

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.

[Devdatta Akhawe]

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 <re...@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...@chromium.org.