Tracking down intermittent stale request errors from the IdP

Wessel, Keith kwessel at illinois.edu
Fri Jun 1 17:38:20 EDT 2018


Interesting possibility. You're suggesting he's switching nodes half way through the login process, right?

It is load balanced, but with session stickiness enabled and a five-minute sticky period. And during the time that this happened today, there were no hits from his IP address in the web server log. His last hit on the other node was at 12:09. He successfully logged into a service at 12:30 then got the error a minute later at 12:31 on the same node.

Keith


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Andrew Morgan
Sent: Friday, June 1, 2018 3:47 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Tracking down intermittent stale request errors from the IdP

On Fri, 1 Jun 2018, Wessel, Keith wrote:

> All,
>
> Hoping someone can point me in the right direction. We have a technical 
> user here on campus who has been getting intermittent stale request 
> messages from the IdP. He'll sign into a service behind Shib then, when 
> he signs into another, he'll be prompted to re-enter his password even 
> though forced reauth wasn't requested and he still has a valid IdP 
> session. After clicking the login button on that page, he'll get a stale 
> request message in his browser instead of being prompted for 2FA.
>
> When this happens, he can go back to the same starting point for logging 
> into the service several times in a row and get the same results until, 
> after a few tries, it randomly works. He can even try in a private 
> browsing window and get the same results while it's still happening.
>
> So far, this has all been in Chrome and hasn't been happening to other 
> customers, or at least they're not reporting it. But he's been putting 
> up with it every couple days for the last couple months. It happens to a 
> variety of SPs, but he's never had it happen when logging into AWS 
> (which he does frequently) which uses IDP-initiated SSO.
>
> He's tried the obvious clearing his cache and disabling browser 
> extensions.
>
> All that the IdP reports in the log is a no such flow exception.
>
> I suspect his browser is doing some funny caching that it shouldn't be. 
> I'm tempted to have him re-install Chrome or spend a few days in another 
> browser. Before I do, wondered if anyone had suggestions of other things 
> I might try to help troubleshoot this.

Keith,

Is your IDP load balanced with multiple nodes?  This sounds like the 
JSESSION is being lost, which can happen if his requests go to different 
(un-replicated) nodes as part of the login process.

We ran into this problem when we moved some nodes into AWS behind the 
Network Load Balancer.  The NLB does not support sticky sessions, so the 
JSESSION and web flow would be lost when a client switched nodes between 
the steps of the login flow.

Thanks,
 	Andy
-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


More information about the users mailing list