IDP 5 - NoSuchConversationException when clicking URL link from email and _saml_idp cookie set.

[Dan McLaughlin]

The Sec-Fetch-Site request header is part of a set of headers that
browsers automatically add to HTTP requests to provide additional
context about the request's origin. These headers are used for
security purposes, particularly to help with Cross-Origin Resource
Sharing (CORS) and other security policies.  The only way I could find
to override the header was by using a reverse proxy, but doing that
would defeat the purpose of the header.

I've done a LOT of reading on this, and I don't think it's a bug in
the browsers. The behavior doesn't seem to be part of any
specification (not that I've found anyway), but it seems that all of
the browsers have decided to follow Chrome's lead.

One thing to keep in mind here is that in our case the IDP that's
having issues happens to be on the same site (domain) as the
applications it's handling logins for. It's an IDP that does DB
authentication using custom authentication; we provide it for some of
the end users who don't have an IDP they can log in with because they
don't have the IT staff to manage an IDP.

When the saml_idp cookie is present, the SP knows which IDP the user
last authenticated with, so when they click the link in the email, the
browser sets the Sec-Fetch-Site=cross-origin header on the initial
request since the origin (gmail, outlook client, etc...) are not on
the same domain as the link in the email was taking them to, once set,
it will not change, and all subsequent redirects will continue to
contain that header.  The browser will then check before it sends
every request and if Sec-Fetch-Site=cross-origin, then any cookies
that are marked SameSite=Strict are not going to be added as a cookie
to any request.   The first redirect to the IDP is when the
__Host-JSESSIONID is set, and you can see in the DevTools that the
browser has the cookie, but then the IDP redirects to
/idp/SSO?execution=e1s1 and when it does the browser makes the
request, but because the __Host-JSESSIONID has SameSite=Strict and the
Sec-Fetch-Site still says cross-origin, none of the browsers are
adding the __Host-JSESSIONID to the request, they all behave the same
way.   Once I change the __Host-JSESSIONID SameSite=lax, the cookie
will be sent.    And the only reason it works when saml_idp cookie
isn't set is that the DS makes the user click something that builds a
new request with the destination as url parameter, basically creating
a new request, so the browser changes Sec-Fetch-Site from
cross-origin, to same-site.

I've tested Firefox, Safari, Chrome (Canary and Nightly), Edge, and
even Opera GX.   The only two that aren't using the Chromium engine
are Firefox and Safari, but they also follow the same behavior.

The only way to use SameSite=Strict and have cross-origin requests
still work is for you to build some intermediate site that all your
email links point to that is on the same site as the destination page,
and you have to do something to get the user to create a new request,
essentially like the DS ends up doing.


--

Thanks,

Dan

On Mon, Nov 27, 2023 at 3:50 PM Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> > The problem was consistent across every browser we tried. If the
> > Sec-Fetch-Site=cross-origin header is on the request...
>
> Does the IdP actually see that header? I assume so.
>
> It sounds like we should log it, because whatever is doing this is just plain broken (and if every browser is broken, all that does is prove I was right a long time ago about that).
>
> We have ample experience running IdPs without any SameSite adjustments, and SPs that route directly to the IdP have never had this sort of problem before. It seems like the trick to this is understanding why/when they send that header, so logging it probably is a first step to getting a better grasp of that.
>
> It's possible that things are just way worse than they used to be and something's changed. I haven't run my IdP without SameSite in quite a while, so it's certainly possible it isn't optional to handle that anymore even for routine cases.
>
> -- Scott
>
>