Improve UX on Single Logout using SAML

[elasticmachine]

Original comment by @jkakavas:

When Single Logout is enabled and functional, the user ends up in a loop

1. User clicks on "Logout" in Kibana
2. Browser makes request to /api/security/v1/logout
3. Response is a 302 to SLO redirect URI of the Idenity Provider
4. Browser accesses the SLO redirect URI and Identity Provider stops the session
5. Identity Provider redirects to the SLO endpoint in Kibana with the LogoutResponse in the GET parameter
6. Kibana passes that LogoutResponse to Elasticsearch in /api/security/v1/logout
7. Response is a 302 to /
8. Browser accesses / and authentication is triggered, user is redirected to the Identity Provider
9. If the user already has a session with the Identity Provider, we have a case of LINK REDACTED , otherwise the user is presented with a login form.
   Perceived user experience is that they click on logout and they are redirected to page to log in.

UX issues are similar to LINK REDACTED and solutions are similar :

• Disable lazy session initialization in Kibana, by enabling a splash screen with button (i.e. Sign in with SAML) - This is what Pingboard does for example.
• Have an after-logout landing screen

[kcm]

We just implemented an Okta SAML 2.0 integration with Kibana/ES. By default, the user will end up in an endless authentication loop:

With an Okta SAML 2.0 app, the SSO URL is navigated to when the user clicks on the Okta app. The user is then authenticated properly, but is redirected back to the original target URL - which was the SSO URL, so the process repeats in an endless loop.

As a workaround, we created a bookmark app in Okta that points to the top-level Kibana page, and hid the (active) SAML 2.0 app without disabling it. By navigating to the top-level, the user properly then authenticates via the SAML app, and navigates back to the top level page on success.

One possible enhancement here is to provide an optional redirection target for successful external authentication, and possibly default to the top level page.

[jkakavas]

@kcm have you seen this: [removed] They seem to be getting a different behavior with the same OKTA settings. Can you compare and share your feedback?
Also it would be very interesting to see the log from your browser console when this redirection loop happens, would it be possible to capture at least the URLs visited and the response headers?

[kcm]

@jkakavas we did everything listed in LINK REDACTED.

It did start working today, sporadically. Looks like something is being cached on the server side. I've isolated the following behavior:

• Open Chrome Incognito window
• Navigate to /login (works as basic, didn't log in)
• Navigate to / (works as SAML, didn't log in)
• Navigate to /login (doesn't work, redirects to SAML)

The logs show a 200 for the first /login and 302 for the second /login. Here's the 302 and following verbose logs:

{"type":"response","@timestamp":"2018-05-08T17:25:06Z","tags":[],"pid":26369,"method":"get","statusCode":302,"req":{"url":"/login","method":"get","headers":{"host":"prd-elasticm2","connection":"keep-alive","upgrade-insecure-requests":"1","user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36","accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8","dnt":"1","accept-encoding":"gzip, deflate, br","accept-language":"en-US,en;q=0.9"},"remoteAddress":"10.125.34.59","userAgent":"10.125.34.59"},"res":{"statusCode":302,"responseTime":4,"contentLength":9},"message":"GET /login 302 4ms - 9.0B"}
{"type":"log","@timestamp":"2018-05-08T17:25:06Z","tags":["debug","security","saml"],"pid":26369,
"message":"Trying to authenticate user request to /."}
{"type":"log","@timestamp":"2018-05-08T17:25:06Z","tags":["debug","security","saml"],"pid":26369,
"message":"Trying to authenticate via header."}
{"type":"log","@timestamp":"2018-05-08T17:25:06Z","tags":["debug","security","saml"],"pid":26369,
"message":"Authorization header is not presented."}
{"type":"log","@timestamp":"2018-05-08T17:25:06Z","tags":["debug","security","saml"],"pid":26369,
"message":"Trying to authenticate via state."}
{"type":"log","@timestamp":"2018-05-08T17:25:06Z","tags":["debug","security","saml"],"pid":26369,
"message":"Access token is not found in state."}
{"type":"log","@timestamp":"2018-05-08T17:25:06Z","tags":["debug","security","saml"],"pid":26369,
"message":"Trying to authenticate via SAML response payload."}
{"type":"log","@timestamp":"2018-05-08T17:25:06Z","tags":["debug","security","saml"],"pid":26369,
"message":"SAML response payload is not found."}
{"type":"log","@timestamp":"2018-05-08T17:25:06Z","tags":["debug","security","saml"],"pid":26369,
"message":"Trying to initiate SAML handshake."}
{"type":"log","@timestamp":"2018-05-08T17:25:06Z","tags":["debug","security","saml"],"pid":26369,
"message":"Redirecting to Identity Provider with SAML request."}

[kobelb]

Adding the "successfully logged out page" solved a majority of the issues described here. I've created #39313 to track the creation of the "auth provider selection" splash-screen before login for the final way we could improve this situation.