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

[Dan McLaughlin]

I have a correction to make, Safari only seems to work because for
some reason it doesn't forward the saml_idp cookie, so it always goes
to the DS.  But Firefox behaves the same as Chrome.

--

Thanks,

Dan

On Mon, Nov 27, 2023 at 5:35 PM Dan McLaughlin
<dmclaughlin at tech-consortium.com> wrote:
>
> 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
> >
> >