[Discuss] Support for authenticating users via proxy-based mechanisms

[legrego]

This is a work in progress, and not ready for discussion.

📚 Background

We expect that a vast majority of installations utilize our Login Selector/Login Form to authenticate their human end-users.

Administrators who do not wish to use our login selector will often put a reverse proxy in front of Kibana to handle authentication. In these setups, the proxy is responsible for sending an Authorization header to Kibana on each and every request. When configured in this fashion, we "support" the following schemes:

• Basic for authenticating via username/password
• ApiKey for authenticating via an Elasticsearch API Key
• Bearer for authenticating via an Elasticsearch Token
• <custom_scheme> for authenticating via some bespoke mechanism.

All of these make use of Kibana's HTTP Authentication provider. We typically expect that this will be used for machine-to-machine communication for singular API calls -- in other words, not a human using Kibana in an interactive fashion. That said, we do know that a small number of installations ^{[citation needed]} take advantage of this to authenticate their humans for interacting with Kibana via a web browser.

In addition to providing the Authorization header via reverse-proxy, a subset of them will also provide a es-security-runas-user header, which is then passed through to Elasticsearch in order to allow the authenticated user to impersonate another user of the proxy's choosing.

💔 Current complications

Using this setup today (the 7.x era) works for most cases, but there are some known limitations:

Unable to create alerts when authenticating via API Keys

Related: elastic/elasticsearch#59304

Kibana's alerting framework is unable to generate API Keys when the user attempting to create an alert a rule is themselves authenticated to Kibana via an API Key. The "Grant API Key" API that alerting uses under the hood does not allow an API Key to create another API Key.

Unable to create Alerting API Keys with the permissions of the es-security-runas-user user

The API Keys created by the alerting framework do not respect the privileges of the impersonated user. They are instead created with the permissions of the authenticated user.

Unable to manage user sessions

When the Authorization header is provided to Kibana, we bypass the traditional login process: there is no login selector, login form, or SSO negotiation performed.

This also means that we do not create a Session for this request. This precludes these setups from taking advantage of our session management features (idle timeout, session lifespan).

🔮 Future complications

Personalizing the Kibana experience

We want to provide a more personalized experience for our users. This may include features such as:

• Per-user settings, such as
  • dark mode preferences (Dark Mode per User #48687)
  • favorite space (Spaces - User specific favorite space #21640)
• Notifications ([RFC] Kibana notification service  #90297)

Collaborating with other users

Both the security and observability solutions are looking to build collaborative features, most notably within Cases. Here, they would benefit from being able to:

• Assign users to a case
• @mention other users within a case (Support "@"mentioning other users #80334)

🗣️ The Discussion

The ability to personalize the user experience, and allow users to collaborate with one another first requires us to uniquely identify each user. That leads to us asking: "What is a user?"

The Kibana and Elasticsearch security teams posit that an API Key is not a user, and that an API Key is not necessarily under the control of the user that created it. In other words, these are not designed to be used as "personal access tokens".

Do we want to support humans authenticating to Kibana via API Keys for interactive use?

If we didn't already have this functionality in the wild, then I think this would be an easy decision. Given that we know about installations that use Kibana in this fashion, the decision becomes a bit more difficult.

Do we want to support humans authenticating to Kibana via basic/bearer schemes for interactive use?

IMO this is less of an issue. They won't be able to take advantage of our session-based features, but there are no user identity concerns with this approach, and alerting will continue to function as normal.

Do we want to support any of the above in tandem with "es-security-runas-user"?

API Keys: TODO

Basic/Bearer: TODO

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)