No such flow exception help

[Wessel, Keith]

And initial testing of that theory indicates that it breaks approximately 2 minutes after first authentication, too. Setting the condition for the servlet filter to true, and I can't reproduce the error thus far. So, sadly, I believe you're right.

I'm not sure why this isn't happening with our proxying to ADFS but it is to AzureAD. Different headers from Microsoft's cloud servers, perhaps?

For proxying situations like this, the only solution is to enable the samesite filter, correct? And if we don't want to make users with older browser suffer, we'll need to come up with the user agents for which we want it to fire? Just making sure there's no other option before I go down this road.

Keith


-----Original Message-----
From: Cantor, Scott <cantor.2 at osu.edu> 
Sent: Tuesday, August 9, 2022 1:44 PM
To: Shib Users <users at shibboleth.net>
Cc: Wessel, Keith <kwessel at illinois.edu>
Subject: Re: No such flow exception help

On 8/9/22, 2:31 PM, "users on behalf of Wessel, Keith via users" <users-bounces at shibboleth.net on behalf of users at shibboleth.net> wrote:

>    Ugh. I suspected it might be something like this. I'm confused why we
> aren't seeing it consistently. For instance, it usually doesn't happen on the
> first authentication request of an IdP session, and sometimes not on the
. second authn request, either. I often have to hit the IdP with two or three
> authn requests before I get a stale request error.

Thank Google for that, they decided to implement the 2 minute grace window. I happen to think that "make it work, kind of, sometimes, but not predictably" is NOT better than "fail consistently, always", but they don't agree. I wrote that less politely the first time.

> If I do this, would I set the idp.sameSite.cookiie to Lax or Strict or leave it at
> None? Still trying to get my head around the meaning of the settings for
> that parameter.

A SAML assertion submission uses POST, it has to be None.

-- Scott