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

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

    XMLWordPrintable

Details

    • Bug
    • Resolution: Duplicate
    • Major
    • None
    • None
    • Security
    • False
    • None
    • False
    • Workaround Exists
    • Hide

      Deploy apps together in an ear configured for session sharing.

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

    Description

      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.

      Attachments

        Issue Links

          duplicates

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-25796 [GSS](7.4.z) ELY-2589 - Elytron SSO does not expire other application sessions for session invalidation like Undertow SSO promptly following sessionid change

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Verified
          incorporates

          Bug - A problem that impairs or prevents the functions of the product. WFLY-17627 Elytron SSO does not properly track multiple application sessions

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Open
          is cloned by

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-25229 [GSS](8.0.z) WFLY-17627 - Elytron SSO does not properly track multiple application sessions

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Activity

            People

              fjuma1@redhat.com Farah Juma
              rhn-support-aogburn Aaron Ogburn
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: