Render a more actionable and user-friendly UI for unhandled login failures #171040
Assignees
Labels
enhancement
New value added to drive a business result
Feature:Security/Authentication
Platform Security - Authentication
Team:Security
Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Comments
azasypkin
added
Team:Security
|
Pinging @elastic/kibana-security (Team:Security) |
SiddharthMantri
added a commit
that referenced
this issue
Mar 28, 2024
## Summary Closes #171040 ## Fixes - Added a specific check for 500 errors when auth fails with OIDC/SAML - Renders unauthenticated page with the redirect set for `/` ## Steps to test There are multiple ways to test the scenarios for rendering the unauthenticated use case. ### Use existing testing configs to run Kibana with different configurations: Changes added to the test suite here: [x-pack/test/security_functional/plugins/test_endpoints/server/init_routes.ts](https://github.com/elastic/kibana/pull/173959/files#diff-d4d10bb4dd30278eac5887d8be2ce2a9638d7741209be2ece7c0600e422175fd) assist in the testing of the scenarios. 1. Login selector is enabled ``` node scripts/functional_tests_server.js --config x-pack/test/security_functional/login_selector.config.ts ``` 2. Login selector is disabled, login page is available, but not default == we ignore the existence of /login UI ``` node scripts/functional_tests_server.js --config x-pack/test/security_api_integration/saml.config.ts ``` 3. Login selector is not enabled, but login page is available and default ``` node scripts/functional_tests_server.js --config x-pack/test/security_api_integration/http_bearer.config.ts ``` Now, when you run Kibana in any of these test configurations you must first navigate directly to http://localhost:5620/login to log in as elastic user and then access the following URLs and see how the code behaves ``` http://localhost:5620/authentication/app/not_auth_flow http://localhost:5620/authentication/app/not_auth_flow?statusCode=400 http://localhost:5620/authentication/app/not_auth_flow?statusCode=401 http://localhost:5620/authentication/app/not_auth_flow?statusCode=500 # Auth flow routes - part of the auth flow http://localhost:5620/authentication/app/auth_flow http://localhost:5620/authentication/app/auth_flow?statusCode=400 http://localhost:5620/authentication/app/auth_flow?statusCode=401 http://localhost:5620/authentication/app/auth_flow?statusCode=500 ``` ### Run kibana as usual for testing To test this by running kibana locally, you'll first need to set up your local instance to run with SAML - Login to https://oktanaut.app.elastic.dev/ - Fill in your local endpoint - Set Stack version 8.0+ and platform to Other Then with the cofigs given to you from there, run ES as follows: ``` yarn es snapshot --license trial \ ... your config ``` and then run KBN as ``` yarn start --no-base-path \ -xpack.security.authc.selector.enabled=false ... rest of the config from Oktanaut goes here ``` This will start up your local stack pointing to SAML. At this point, we need to force an error to test this flow. There are a few ways to do that: #### Option A - Go to the SAML provider in [`/x-pack/plugins/security/server/authentication/providers/saml.ts`](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security/server/authentication/providers/saml.ts) - Replace [`ids: !isIdPInitiatedLogin ? [stateRequestId] : [],` with `ids: []`](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security/server/authentication/providers/saml.ts#L372) - Comment out the line [`...(providerRealm ? { realm: providerRealm } : {})`](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security/server/authentication/providers/saml.ts#L374) #### Option B You could also do the following to reproduce the error on main: - Open kibana in a private browser window. - Then start the login flow which redirects you to okta. - Before entering your password, switch off the ES instance running locally. - Then login which should give you a redirect back to the saml/callback page with an error JSON. In the PR, this should give you the unauthenticated screen #### Option C Force one (or both) of the Kibana (SAML/OIDC) routes to throw a custom error For example, in `x-pack/plugins/security/server/routes/authentication/saml.ts:L64`, add the following code snippet ```ts return response.customError({ statusCode: 500 }); ``` Now running through the SAML login flow on main should show a JSON error string whereas this PR should show an unauthenticated error page. This sends a bad request to the SAML provider which results in the error which should now show you an Unauthenticated page. ## Release Notes: - Renders a user-friendly UI for unhandled login failures. #171040 --------- Co-authored-by: Kibana Machine <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
Today, when a user fails to log in with SAML or OIDC due to an unexpected reason (e.g., ES returns any error code apart from 401), we might return a non-descriptive 500 error that is directly rendered in the user's browser as a JSON string (this scenario is handled in
kibana/x-pack/plugins/security/server/authentication/authentication_service.ts
Line 198 in 2c90ba9
Ideally, we should render something more helpful and actionable so that the user can repeat the login. For example, our 'Authentication error' dialog.
The text was updated successfully, but these errors were encountered: