Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-5932

Invalidating a session of an SSO on a different node than where the session was created does not logout the user

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Blocker Blocker
    • 11.0.0.Beta1
    • 10.0.0.CR5
    • Web (Undertow)
    • None
    • Hide
      • Two servers with a distributable deployment capable of calling Session.invalidate() (FORM auth), clustered single-sign-on, user added
        • A1 = 127.0.0.1:8080/deployment
        • A2 = 127.0.0.2:8180/deployment
      • Access A1, authenticate, access A2 (we still only have a single session - everything distributable), invalidate session on A2 (e.g. calling 127.0.0.1:8180/deployment?invalidate=true), access A2:
        • Expected: we need to authenticate and then receive a new session
        • Actual result: we receive a new session but don't need to authenticate
      Show
      Two servers with a distributable deployment capable of calling Session.invalidate() (FORM auth), clustered single-sign-on, user added A1 = 127.0.0.1:8080/deployment A2 = 127.0.0.2:8180/deployment Access A1, authenticate, access A2 (we still only have a single session - everything distributable), invalidate session on A2 (e.g. calling 127.0.0.1:8180/deployment?invalidate=true), access A2: Expected: we need to authenticate and then receive a new session Actual result: we receive a new session but don't need to authenticate

      See steps to reproduce for description. Additional scenario with a failover where we don't need to authenticate with the last request (but where we should be required to authenticate):

      • Access A1, authenticate, fail A1 (e.g. shutdown the server), access A2, invalidate session on A2, access A2

      Scenarios where the SSO context is destroyed (where we need to authenticate with the last request as expected):

      • Access A1, authenticate, invalidate session on A1, access A1
      • Access A1, authenticate, access A2, invalidate session on A1, access A1

      Possibly related to JBEAP-1228, JBEAP-1282. Note that we always only have a single session bound to an SSO. I'm not flagging this as a blocker, since the issue usually doesn't manifest thanks to sticky sessions on a load balancer.

              pferraro@redhat.com Paul Ferraro
              rjanik@redhat.com Richard Janik
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

                Created:
                Updated:
                Resolved: