Ignore intermediate unauthenticated session during repeated authentication attempt #75338
Labels
bug
Fixes for quality problems that affect the customer experience
Feature:Security/Authentication
Platform Security - Authentication
Team:Security
Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Currently when Authenticator tries to authenticate request with the existing session it rightfully picks provider that owns this session and delegates handling of the request to it.
At this point provider tries to authenticate request with the session information and if it cannot it initiates a new one. But there are cases when we may want to be smarter and analyze the shape of the current session value to decide whether we want to initiate a new session or we want to clear/ignore current one instead.
For example, if user goes to the login UI and selects any SSO authentication we remember that choice in the unauthenticated session and redirect user to the IdP/OP. If something happens on the IdP side and user isn't redirected back to Kibana with the IdP/OP response then they stuck with that intermediate session. That means that when user goes to Kibana again (in the same browsing context aka same window) Authenticator picks up the session and initiates new login attempt with that same provider right away. It's all fine as long as user can eventually log in with the IdP, but if user wants to fall back to another provider (e.g. log in with
elastic
user instead) they have to either 1) go to/login
directly, or 2) go to/logout
directly, or 3) open private tab/clean cookies.SSO providers (SAML and OIDC) can potentially detect that case and instead return
notHandled
signalling to Authenticator that current session may be invalidated and new login flow should be started. If Login Selector is enabled then user will be redirected there, otherwise we'll start new SSO handshake as we do now.The text was updated successfully, but these errors were encountered: