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

[Dan McLaughlin]

The problem was consistent across every browser we tried. If the
Sec-Fetch-Site=cross-origin header is on the request and the saml_idp
cookie is set, then the request goes straight from the SP to the IDP
login page, and when the __Host-JSESSION cookie is set with
SameSite=Strict, the redirect the IDP sends to load e1s1 will not
contain the __Host-JSESSION and so the IDP then fails to find the
session.   There's only three solutions we could find 1) delete the
saml_idp cookie; this will make the client get redirected to the DS;
when that happens and they pick their IDP the Sec-Fetch-Site changes
to same-site, and then the IDP login works.   The other workaround
would be to change all our email links to an intermediate page that
makes the user click a button or something to generate a same-site
request, and then things work.  The other solution is to use
SameSite=Lax.



--

Thanks,

Dan

On Mon, Nov 27, 2023 at 10:24 AM Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> > 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.
>
> Even so, there's no reason for that to break it. Prevent SSO, perhaps, but not generate an error.
>
> It's possible some of the problems people occasionally run into with Chrome are the same thing you're seeing, but none of it really seems to make much sense because again, the IdP is *not* relying on any cross-site cookie access unless it's been framed.
>
> For this to break it's not just that the initial request lacks the cookie(s), but a subsequent request after the first, and that should be handled as a same-origin request by that point.
>
> I guess it's possible some clients are just broken and not others, but I'm not sure that's the case here.
>
> What has generally caused this problem (and still does) with email links is not something you can fix with SameSite either. Some email clients or apps will launch the request in a local browsing context and handle redirects up to a point before handing the final request off to an "open browser" system call. With that, you get this error because the IdP has already established the start of a conversation but the browser doesn't have the cookies it needs to have at all because they were isolated to the invoking app.
>
> The landing page you mention is one way to fix *that* issue, certainly, possibly the only way at times. SameSite alone won't help.
>
> -- Scott
>
>