Possible causes of NoSuchFlowExecutionException errors

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible causes of NoSuchFlowExecutionException errors

Paul Henson
I am working with a client that has a service they are trying implement
SAML authentication for that is accessible via both a regular web
browser and a mobile app (which is effectively an embedded web browser).

They are having an issue where randomly the mobile app will display the
typical "Stale Request" page after authentication with the usual error
in the logs:

NoSuchFlowExecutionException: No flow execution could be found with key
'e1s2'

My assumption was that the embedded web browser was doing something
stupid occasionally and calling the wrong URL or not providing the right
cookie. However, after setting up an intermediate proxy server to trace
the connection (sadly, no samltracer support using the mobile app) it
seems that is not the case. Comparing a successful transaction and a
failed transaction, both of them seem to make all of the right calls and
pass all of the right cookies.

The only difference is that in the success case after the authentication
the client receives the shib_idp_session_ss and shib_idp_session cookies
along with the assertion to be posted to the SP, and in the failure case
they receive the stale request error along with a new JSESSIONID cookie
different than the one that had been being used throughout the transaction.

It smells like a flaky idp cluster or a load balancer without the proper
session affinity, but evidently this only happens with the mobile app
embedded web browser, never with a normal web browser, and no other
services utilizing the idp run into it.

Are there any other issues that might cause a stale request error such
as this, other than the obvious cases of invalid cookies or broken idp
side state? I'm not quite sure what to look at next…

Thanks much…


--
Signet - The Art of Access
https://www.signet.id/

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Possible causes of NoSuchFlowExecutionException errors

Cantor, Scott E.
On 12/19/19, 8:58 PM, "users on behalf of Paul Henson" <[hidden email] on behalf of [hidden email]> wrote:

> It smells like a flaky idp cluster or a load balancer without the proper
> session affinity

That's what it is. By definition if it sends a new JSESSIONID, the old one either wasn't passed in or it wasn't valid. Since the trace presumably showed the cookie was passed in, there is no obvious alternative except the server it reached wasn't the one that held the session.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Ex: Re: Possible causes of NoSuchFlowExecutionException errors

Paul Henson
On 12/19/2019 6:03 PM, Cantor, Scott wrote:
>
> That's what it is. By definition if it sends a new JSESSIONID, the
> old one either wasn't passed in or it wasn't valid. Since the trace
> presumably showed the cookie was passed in, there is no obvious
> alternative except the server it reached wasn't the one that held the
> session.

Thanks much for the confirmation and the insanely rapid response :).

I'm confused then, unless I'm missing something in the trace of the
transaction if this were an endemic idp side issue I would expect the
failure to also occur using a normal desktop browser for this
application as well as with all of the other applications that might use
the idp, which I am told is not the case.


--
Signet - The Art of Access
https://www.signet.id/
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Possible causes of NoSuchFlowExecutionException errors

Cantor, Scott E.
In reply to this post by Paul Henson
On 12/19/19, 9:11 PM, "users on behalf of Paul Henson" <[hidden email] on behalf of [hidden email]> wrote:

> I'm confused then, unless I'm missing something in the trace of the
> transaction if this were an endemic idp side issue I would expect the
> failure to also occur using a normal desktop browser for this
> application as well as with all of the other applications that might use
> the idp, which I am told is not the case.

Even if that's true, that just means the vagaries of the LB algorithm are only impacting that network, client, or whatever other variables are unique to the mobile app. If nothing else, I'd want to know if the same devices on the same networks using a browser showed anything different.

The key is the updated JSESSIONID coming back. That rules out most of the other possibilities.

But the server logs are obviously the real story. Adding JSESSIONID to the logs is the best way to track which servers are being hit.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]