I'm using the single-sign-on feature on Wildfly 10.1.0.Final. I have a non-clustered environment - the SSO is used to login a user across different context roots: multiple WARs deployed on the same WildFly instance.
The login process works as expected, I get a JSESSIONIDSSO cookie and the user can access all context roots.
The problem occurs after the login, when multiple asynchronous REST requests to the same REST endpoint are made from the same client.
This causes creation of a new session for each request but only one of the created sessions is added to SSO object, although all of them use the same JSESSIONIDSSO. New sessions are created only when incoming request doesn't contain the JSESSIONID for the requested context root, but only the JSESSIONIDSSO. I would expect that multiple requests coming from the same client would create only one session, which will then be reused for all other requests coming from the same client to selected context root.
This means that once the SSO is invalidated, it this invalidates only one session per WAR, and other sessions are left hanging.
When I login again the hanging sessions can be reused. This means that Undertow recognizes that request is coming from the same client, and decides to reuse the existing session instead of creating the new one, which makes perfect sense - question is why the same principle isn't used when multiple requests are made?
Is it possible to configure Undertow to create only one session per context root for each client? Or perhaps to configure Wildfly to associate all created sessions to SSO, so when SSO is invalidated all created sessions are terminated as well?
Thanks and regards
Have you resolved this meanwhile ?
We also have the same problem when using SSO.
A new session is created for each rest request coming from another app deployed on the same server.