Occasional NoSuchFlowExecutionException errors on IdP with Safari after longer inactivity

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Occasional NoSuchFlowExecutionException errors on IdP with Safari after longer inactivity

Daniel Lutz
Some of our users use Safari on macOS. Occasionally, if they haven't closed Safari
for several days and haven't accessed the IdP for one or more days, they experience
"Stale Request" errors (NoSuchFlowExecutionException). We aren't aware of this problem
with other browsers.

We run the IdP in Tomcat behind Apache.

Has anyone experienced similar problems with Safari and the Shibboleth IdP
(running on Tomcat)?


I assume that the problem is related to the JSESSIONID cookie.
To analyze the problem, I configured the Apache logs to log the JSESSIONID
cookie sent by the browser and set by the IdP (or Tomcat, respectively).
I found the following behavior:

In the first HTTP request (SAML AuthnRequest), the browser sends an outdated JSESSIONID
value. The response is a redirection to a WebFlow URL ("e1s1"). The server sets a
new JSESSIONID with a new value. (This seems to be correct, as the JSESSIONID value
sent by the browser doesn't belong to an existing session.)

Here are the corresponding logs:

  Apache: ... [22/May/2018:06:39:20 +0200] "GET /idp/profile/SAML2/Redirect/SSO?SAMLRequest=fZHNTuswEIV... HTTP/1.1" 302 ...
  IdP:    2018-05-22 06:39:20,716 - DEBUG [net.shibboleth.idp.saml.profile.impl.InitializeRelyingPartyContextFromSAMLPeer:132] - ... [jsessionid=DF4B324B1CDFD657D0EEE308599EBFCE,remote_addr=...]

  Cookie sent by the browser: JSESSIONID=82AC2DFE916D2BA1BC082A9546D1CF09 (old value, set on 2018-05-18)
  Cookie set by the server:   JSESSIONID=DF4B324B1CDFD657D0EEE308599EBFCE; Path=/idp; Secure; HttpOnly

The browser is redirected to the WebFlow URL with conversation id "e1s1".
In the subsequent HTTP request, Safari seems to send another outdated JESESSIONID value,
although it should send "DF4B324B1CDFD657D0EEE308599EBFCE". It seems to me that it didn't
update the JSESSIONID cookie, but used one of several older values it knew.

Here are the corresponding logs:

  Apache: ... [22/May/2018:06:39:20 +0200] "GET /idp/profile/SAML2/Redirect/SSO?execution=e1s1 HTTP/1.1" 200 ...
  IdP:    2018-05-22 06:39:20,744 - ERROR [org.springframework.webflow.execution.repository.NoSuchFlowExecutionException:76] -  [jsessionid=B51360242F1EB675A259AC220AC3BD90,remote_addr=...]

  Cookie sent by the browser: JSESSIONID=FAEC94ADDA21F9A5E9B7643CA1C888FF (set on 2018-05-18)
  Cookie set by the server:   JSESSIONID=B51360242F1EB675A259AC220AC3BD90; Path=/idp; Secure; HttpOnly

BTW, all requests use HTTPS, the HTTTP Host name is always the same, the client's IP address is always
the same (IPv6),  and there are no frames/iframes involved.

We run Tomcat more or less in its default configuration, which seems to set JSESSIONID
as a session cookie. In /opt/shibboleth-idp/edit-webapp/WEB-INF/web.xml, we have configured
"COOKIE" only as tracking mode.


Which could be the problem here? May it be related to Safari, Apache, Tomcat, Spring WebFlow or the IdP?


Thanks for any hints.


- Daniel
--
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: Occasional NoSuchFlowExecutionException errors on IdP with Safari after longer inactivity

Cantor, Scott E.
> The browser is redirected to the WebFlow URL with conversation id "e1s1".
> In the subsequent HTTP request, Safari seems to send another outdated
> JESESSIONID value, although it should send
> "DF4B324B1CDFD657D0EEE308599EBFCE". It seems to me that it didn't update
> the JSESSIONID cookie, but used one of several older values it knew.

That would certainly break it. Can't get much more fundamentally broken than that.

> Which could be the problem here? May it be related to Safari, Apache, Tomcat,
> Spring WebFlow or the IdP?

Presumably a browser bug unless the new cookie doesn't match the full specification of the old one in regard to path, domain, etc. If you only see it with Safari, and if it superficially seems to be failing to update the cookie, that's pretty definitive. Safari has a long history of bugs of all kinds when it comes to the kinds of interactions involved with SSO systems, so this is not surprising.

-- 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
|

Occasional NoSuchFlowExecutionException errors on IdP with Safari after longer inactivity

Daniel Lutz
Cantor, Scott [22.05.18 16:21]:
> Presumably a browser bug unless the new cookie doesn't match the full specification of the old one in regard to path,
> domain, etc. If you only see it with Safari, and if it superficially seems to be failing to update the cookie, that's
> pretty definitive. Safari has a long history of bugs of all kinds when it comes to the kinds of interactions involved
> with SSO systems, so this is not surprising.

Thanks a lot for this feedback, Scott.
So I can be fairly sure that the problems are caused by bugs in Safari.

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