Details

    • Type: Sub-task
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 3.1.0.Final
    • Fix Version/s: 3.3.0.CR2
    • Component/s: None
    • Labels:
      None
    • Docs QE Status:
      NEW
    • QE Status:
      ASSIGNED

      Description

      The algorithm in AuthenticationManager.browserLogout works in a way that:

      • It finds the userSession and tracks all the clients supporting backchannel logout. The Logout request is sent to them
      • For the frontchannel logout, which is currently supported just for SAML, there is a chain of browser redirects . The particular client redirects back to keycloak after doing it's logout and then Keycloak redirects to other frontchannel client. Keycloak tracks, which client needs to be logged-out through the update on userSession. So currently when there is userSession with N fronchannel clients, there are N+1 updates to the userSession during logout before userSession is finally removed.

      I think that for cross-dc. we may optimize to have just 1 write to userSession. We can improve this by:

      • Using iframes for the frontchannel logout. There is some discussion on ML [1] . Using iframes has some other advantages and generally it's much better and more robust than browser redirects approach. Extracted to KEYCLOAK-5449
      • Still use redirects, but create the temporary authenticationSession with the action LOGOUT, which will be used just to track the logout state of individual clients. userSession can be removed before this authenticationSession is created and the rest of the logout process will rely on the browser sticky sessions provided by AUTH_SESSION_ID cookie.

      [1] http://lists.jboss.org/pipermail/keycloak-dev/2017-May/009267.html

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                hmlnarik Hynek Mlnařík
                Reporter:
                mposolda Marek Posolda
                Tester:
                Vlastislav Ramik
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: