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

[GSS](8.0.z) ELY-2589 - Elytron SSO does not expire other application sessions for session invalidation like Undertow SSO promptly following sessionid change

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 8.0 Update 2
    • None
    • Security
    • None

      Previously using Undertow SSO as shown here, all sessions associated with an SSO id would be invalidated when one session associated with it is manually invalidated.

      This is quite different with Elytron SSO. It is trying to make a call back to attempt a logout of other participant sessions, but that does not work if that call back URI happens to be protected. For instance, this trace shows a logout call back being attempted but being given the FORM login page response:

      2023-09-05 13:39:39,871 DEBUG [io.undertow.request] (default I/O-4) Matched prefix path /app2 for path /app2/session.jsp
2023-09-05 13:39:39,872 TRACE [io.undertow.server.handlers.resource.PathResourceManager] (default I/O-4) Found path resource session.jsp from path resource manager with base /home/aogburn/code/03598968/wildfly-29.0.1.Final/standalone/deployments/ssotest.ear/app2.war/
2023-09-05 13:39:39,872 TRACE [org.wildfly.security.http.servlet] (default task-2) Created ServletSecurityContextImpl enableJapi=true, integratedJaspi=true, applicationContext=default-host /app2
2023-09-05 13:39:39,872 DEBUG [io.undertow.request.security] (default task-2) Security constraints for request /app2/session.jsp are [SingleConstraintMatch{emptyRoleSemantic=PERMIT, requiredRoles=[user]}]
2023-09-05 13:39:39,873 DEBUG [io.undertow.request.security] (default task-2) Authenticating required for request HttpServerExchange{ POST /app2/session.jsp}
2023-09-05 13:39:39,873 DEBUG [io.undertow.request.security] (default task-2) Setting authentication required for exchange HttpServerExchange{ POST /app2/session.jsp}
2023-09-05 13:39:39,873 TRACE [org.wildfly.security.http.servlet] (default task-2) No AuthConfigProvider for layer=HttpServlet, appContext=default-host /app2
2023-09-05 13:39:39,873 TRACE [org.wildfly.security.http.servlet] (default task-2) JASPIC Unavailable, using HTTP authentication.
2023-09-05 13:39:39,873 TRACE [org.wildfly.security] (default task-2) No CachedIdentity to restore.
2023-09-05 13:39:39,873 TRACE [org.wildfly.security] (default task-2) Created HttpServerAuthenticationMechanism [org.wildfly.security.auth.server.SecurityIdentityServerMechanismFactory@4911d3ee] for mechanism [FORM]
2023-09-05 13:39:39,873 TRACE [io.undertow.request] (default task-2) Created form encoded parser for HttpServerExchange{ POST /app2/session.jsp}
2023-09-05 13:39:39,876 TRACE [org.wildfly.security] (default task-2) Handling SocketAddressCallback
2023-09-05 13:39:39,878 TRACE [org.wildfly.security] (default task-2) Handling MechanismInformationCallback type='HTTP' name='FORM' host-name='localhost' protocol='http'
2023-09-05 13:39:39,878 TRACE [org.wildfly.security.http.form] (default task-2) Trying to re-authenticate. There is no session attached to the following request. Request URI: [http://localhost:8080/app2/session.jsp], Context path: [/app2]
2023-09-05 13:39:39,883 TRACE [org.wildfly.security] (default task-2) Handling CachedIdentityAuthorizeCallback: principal = null  authorizedIdentity = null
2023-09-05 13:39:39,887 TRACE [io.undertow.session] (default task-2) Setting session cookie session id RSl5cd8acyAlWt0ctW16ZadKbxc1nqPQs_4WuzRr.aogburn on HttpServerExchange{ POST /app2/session.jsp}
2023-09-05 13:39:39,888 TRACE [io.undertow.server.handlers.resource.PathResourceManager] (default task-2) Found path resource login.html from path resource manager with base /home/aogburn/code/03598968/wildfly-29.0.1.Final/standalone/deployments/ssotest.ear/app2.war/
2023-09-05 13:39:39,891 TRACE [io.undertow.server.HttpServerExchange] (default task-2) Starting to write response for HttpServerExchange{ POST /app2/login.html}
2023-09-05 13:39:39,901 DEBUG [org.wildfly.security] (default task-1) Destroying SSO [5aaZDwrjfhHkHzSjQrtxpf91NDx5rOzH8Gcb92Yf]. Participant list not empty.

      The app2 logout callback fails in that flow because of a change in the session id. So the /app2/session.jsp request initially creates id session-2a and ties that to the SSO; upon authentication completion, it changes the the id to a new value (session-2b). That changed session id is not tied to the SSO yet so the logout callback from request c is attempted with id session-2a, which doesn't match to invalidate the session now with id session-2b; the request is then handled with an authentication attempt to cause that confusion.

      So if you request /app2/session.jsp twice, the post auth changed session id is associated with SSO and this then avoids the issue:

      a. http://localhost:8080/app1/session.jsp (login alice:alice)
b. http://localhost:8080/app2/session.jsp
c. http://localhost:8080/app2/session.jsp again
d. http://localhost:8080/app1/invalidate.jsp
e. http://localhost:8080/app1/session.jsp (login again)
f. http://localhost:8080/app2/session.jsp (note this doesn't access the same session as request b/c)

      Ideally, we'd need Elytron SSO to be immediately aware of any sessionid change.

            rhn-support-ivassile Ilia Vassilev
            rhn-support-ivassile Ilia Vassilev
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: