Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-25229

[GSS](8.0.z) WFLY-17627 - Elytron SSO does not properly track multiple application sessions

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Major Major
    • None
    • None
    • Security
    • False
    • None
    • False
    • Hide
      Duplicate of JBEAP-26258
      Show
      Duplicate of JBEAP-26258
    • Workaround Exists
    • Hide

      Deploy apps together in an ear configured for session sharing.

      Show
      Deploy apps together in an ear configured for session sharing.

      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.

              rhn-support-ivassile Ilia Vassilev
              pberan@redhat.com Petr Beran
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: