-
Bug
-
Resolution: Duplicate
-
Major
-
None
-
2.1.0.Final
-
Workaround Exists
-
Upon logout, Elytron SSO only invalidates the session for the currently requested app. This leaves lingering sessions in other apps until they reach their idle timeout. That was previously a concern with EAP 6/JBossWeb's SSO and the org.apache.catalina.authenticator.AuthenticatorBase.UNREGISTER_SSO_ON_LOGOUT property was added to enable invalidation of all associated sessions upon logout. Can we add such behavior to Elytron SSO?
In testing with a / app and another non-root app, the apps share a single / path JSESSIONID so I see the logout response clears out the JSESSIONID from the client:
--------------------------RESPONSE-------------------------- contentLength=0 contentType=null cookie=JSESSIONID=RQDpStalqMpdIlamS2j-anNooWkFTFocHD2m5I8-.mlUMzKC9-bnxC8dF0CbfZA; domain=null; path=/ cookie=JSESSIONIDSSO=null; domain=null; path=/ header=Expires=0 header=Cache-Control=no-cache, no-store, must-revalidate header=Set-Cookie=JSESSIONID=RQDpStalqMpdIlamS2j-anNooWkFTFocHD2m5I8-.mlUMzKC9-bnxC8dF0CbfZA; path=/; secure; HttpOnly; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT header=Set-Cookie=JSESSIONIDSSO=; path=/; HttpOnly; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT
So it was invalidated in one app, but now the client can't even access the remaining session in the other app any way so it should have just been invalidated.
It seems Elytron SSO should add a participant session when restoring identity from SSO in a new app. Right now it only ties the first session from the app originally accessed when logging in with SSO. We can see here HttpAuthenticator.login puts the session for the first app during login in SSO:
2023-02-03 15:41:54,083 INFO [stdout] (default task-5) --------------------------->SingleSignOn.addParticipant QqOzdtBZaxpyc7DMj3i8_jZKKwG6X8-Er1fiXgGy 2023-02-03 15:41:54,083 INFO [stdout] (default task-5) org.wildfly.clustering.web.undertow.sso.elytron.DistributableSingleSignOn.addParticipant(DistributableSingleSignOn.java:111) 2023-02-03 15:41:54,083 INFO [stdout] (default task-5) org.wildfly.security.http.util.sso.DefaultSingleSignOnSession.put(DefaultSingleSignOnSession.java:104) 2023-02-03 15:41:54,083 INFO [stdout] (default task-5) org.wildfly.security.http.util.sso.ProgrammaticSingleSignOnCache.put(ProgrammaticSingleSignOnCache.java:90) 2023-02-03 15:41:54,083 INFO [stdout] (default task-5) org.wildfly.security.http.HttpAuthenticator.login(HttpAuthenticator.java:141) 2023-02-03 15:41:54,083 INFO [stdout] (default task-5) org.wildfly.security.http.HttpAuthenticator.login(HttpAuthenticator.java:111) 2023-02-03 15:41:54,083 INFO [stdout] (default task-5) org.wildfly.elytron.web.undertow.server.SecurityContextImpl.login(SecurityContextImpl.java:127) 2023-02-03 15:41:54,083 INFO [stdout] (default task-5) io.undertow.servlet.spec.HttpServletRequestImpl.login(HttpServletRequestImpl.java:503)
But when accessing a second app, the user is authenticated with the identity restored from SSO:
2023-02-03 16:02:24,124 INFO [stdout] (default task-2) --------------------------->DefaultSingleSignOnSession.get CachedIdentity{...} 2023-02-03 16:02:24,124 INFO [stdout] (default task-2) org.wildfly.security.http.util.sso.DefaultSingleSignOnSession.get(DefaultSingleSignOnSession.java:87) 2023-02-03 16:02:24,124 INFO [stdout] (default task-2) org.wildfly.security.http.util.sso.ProgrammaticSingleSignOnCache.get(ProgrammaticSingleSignOnCache.java:77) 2023-02-03 16:02:24,124 INFO [stdout] (default task-2) org.wildfly.security.http.HttpAuthenticator.restoreIdentity(HttpAuthenticator.java:175) 2023-02-03 16:02:24,124 INFO [stdout] (default task-2) org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:90)
And with HttpAuthenticator.restoreIdentity, this new app never has its session added to the SSO entry.
This means the SSO only follows the first session's lifecycle. If you then only access the second app consistently and the first app's session idles out, the SSO is invalidated as well and the user is kicked out of the second app.
- clones
-
WFLY-17627 Elytron SSO does not properly track multiple application sessions
- Resolved
- duplicates
-
ELY-2589 Elytron SSO does not expire other application sessions for session invalidation like Undertow SSO promptly following sessionid change
- Resolved