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

[Dan McLaughlin]

I have found a solution to the issue we were facing. The problem was
that the original request to access a protected resource had come from
an email link, which had caused the browser to set the Sec-Fetch-Site
to cross-origin. To resolve this issue, we will need to add an
intermediate step before directing users to the page the link is
referring to. This intermediate step will change the request to a
same-site request. Alternatively, we could also move back to using Lax
to avoid this problem altogether.

--

Thanks,

Dan

On Wed, Nov 22, 2023 at 10:14 AM Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> > If I use Charles Proxy to add the __Host-JSESSIONID cookie on the
> > request, then things work, so I now know that not having the
> > __Host-JSESSIONID cookie on the request is what causes the IDP error.
>
> Is your web.xml or some other apparatus setting the Path? That has to be set to / for the __Host hack to work. That's the only plausible reason it wouldn't send the cookie deliberately.
>
> Obviously the site setting that cookie and then reading it back are the same, which is why lack of SameSite in general can prevent it from being sent up on the first request to the IdP, so you sometimes end up unable to recover the IdP session and lose SSO, but it still more or less works overall.
>
> I would add, BTW, that quite obviously every SP in the world not using a DS (which is by far most of them) all do this sort of exchange. The discovery cookie is rarely used and its presence can only devolve the interaction to the same one everybody else not using discovery already has, and they obviously work fine.
>
> Has to be an environmental factor, or just something simple like the path being set to /idp like it used to be.
>
> -- Scott
>
>