The kibana login screen displays invalid username and password regardless of the reason for the 401 error which the message is in response to. I had a scenario where I wound up with an Illegal_Argument_Exception while creating a role because I had a typo in one of the cluster permissions for a role that was assigned to the user logging in and I couldn't log in. Not being able to log in is expected but I was being told it was due to username and password.
Steps to reproduce:
elasticExpected behavior:
Error message stating the reason that you are unable to log in (having illegal cluster permission) or something to that effect.
Actual Behavior
Error message stating that username and password are invalid.
Pinging @elastic/kibana-security
@cuff-links Your specific repro steps will be resolved by https://github.com/elastic/elasticsearch/pull/46361, as it will no longer be possible to create a role with invalid cluster privileges.
Are you aware of any other scenarios that the login page should account for, or will this be good to verify/close after the linked PR merges?
@legrego This is the only scenario I was able to reproduce the issue for. If there are any other reasons for 401 errors, though this could cause the same issue.
This is the only scenario I was able to reproduce the issue for. If there are any other reasons for 401 errors, though this could cause the same issue.
Cool, then I'll close this issue once the linked PR merges, and we can revisit if we run into other scenarios in the future. I'd rather address them on a case-by-case basis, as the messages returned from ES can potentially disclose information related to the configured security realms, and we don't want to provide additional context to end-users without first understanding the implications.
As discussed, resolving via https://github.com/elastic/elasticsearch/pull/46361, available in 7.5+
Most helpful comment
Cool, then I'll close this issue once the linked PR merges, and we can revisit if we run into other scenarios in the future. I'd rather address them on a case-by-case basis, as the messages returned from ES can potentially disclose information related to the configured security realms, and we don't want to provide additional context to end-users without first understanding the implications.