Authentication sessions

Authentication session

• Replaces ClientSessionModel
• Entity saved in the infinispan cache
• Valid through the lifecycle of authentication of user

• Tracks the state of authentication
  • authentication executions: which authenticators were already tried and with which results
  • authNotes: notes/attributes, which represents metadata about authentication.
  • clientNotes and other client informations: Info sent through OIDC/SAML protocol used after authentication is finished (EG. Redirect URI)

• authenticationSession is created when OIDC/SAML application redirects to Keycloak login screen
• It lives during whole authentication, requiredActions, consents flow

• authenticationSession is removed once all Keycloak flows finished (right before redirect back to OIDC/SAML application).
• At the same point, userSession with same ID like authenticationSession had is created and SSO cookies are created
• AuthenticatedClientSession is created in cache "clientSessions" and bind with userSession. Some client-specific informations are saved there

• new infinispan cache "authenticationSessions"
• Cache "sessions" now contains just userSession entities
• Cache "clientSessions" now contains just authenticatedClientSession entities
• All are distributed caches with 1 owner by default
• Configurable in infinispan subsystem in standalone(-ha).xml or domain.xml

• Authentication session is tracked with the cookie AUTH_SESSION_ID
• That cookie also provides session stickiness
• Format of the cookie is like <auth-session-id>.<node-id>

Sticky sessions

• Sticky session ensures that loadbalancer forwards all requests from same user (browser) to the same backend node
• Loadbalancer needs to be configured with AUTH_SESSION_ID as sticky session cookie

Who creates the cookie?

• Backend Keycloak server (default and recommended setup)
• Loadbalancer

Cookie added by Keycloak server - example

• Initial request processed on node1
• authentication session with random ID "123" is created
• Infinispan distributed cache decides that ID "123" will be saved (owned) by the distributed cache on node2
• Keycloak then adds the route to the "node2", not to current "node1"

• Great performance - session always available locally
• When ownership changes (rebalance of distributed cache) route in the cookie is automatically updated
• Similar to what Wildfly doing for servlet Http sessions

Disable adding route by Keycloak

• Useful when route (node) needs to be added by loadbalancer instead of backend server
• Adding "shouldAttachRoute" to "false" for StickySessionEncoderProvider
• See docs: http://www.keycloak.org/docs/latest/server_installation/index.html#sticky-sessions
• If route is disabled, Keycloak will use some ID owned by current node
• Still not so optimal like attaching route by Keycloak, as session ownership may be changed to different node upon rebalance

Cookie still exists after authentication

• Cookie AUTH_SESSION_ID still exists after authentication
• Javascript adapter backchannel requests still go to the node which is owner of userSession
• Subsequent SSO requests also go to the same node.
• AuthenticationSession with same ID "123" is re-created upon SSO login