[skip ci] Check point on token provider

[epixa]

do not merge

I'm pushing this as a testable checkpoint for the new token provider implementation.

• Login attempts request service 981685e
• Update basic provider to use login attempts service 5a038ed
• Update change password to use login attempts service 612eeb3
• Stop storing authorization header contents in cookie when using basic auth headers d595fd2
• Extend elasticsearch-js with token APIs c93149a
• Token provider 39942eb
• Authentication logic should only allow one provider be the source of truth for any request #26040 Change how authentication works so there is only ever one source of truth for a request ab788ef

Kibana

You will need extra privileges on the internal server user. Either compile Elasticsearch with elastic/elasticsearch#35751 and use the built-in kibana user, or update kibana.yml with a new user that has the kibana_system role plus a new role that grants access to cluster:admin/xpack/security/token/*:

curl -X POST "localhost:9200/_xpack/security/role/moar_kibana_system" --user elastic:changeme -H 'Content-Type: application/json' -d'
{
  "cluster": [
    "cluster:admin/xpack/security/token/*"
  ]
}
'

curl -X POST "localhost:9200/_xpack/security/user/newbana" --user elastic:changeme -H 'Content-Type: application/json' -d'
{
  "password" : "changeme",
  "roles" : [ "kibana_system", "moar_kibana_system" ],
  "full_name" : "New Kibana",
  "email" : "kibana@example.com"
}
'

Then add this to your kibana.yml:

xpack.security.authProviders: [token]

Elasticsearch

If you're not using TLS in your dev install of Elasticsearch, you'll need to manually enable the token service (note, this won't work for production).

xpack.security.authc.token.enabled: true

The default expiration for tokens is like 30 minutes or something, so you'll probably want to make that smaller while playing around with this if you want to verify the session renewal/refresh token logic:

xpack.security.authc.token.timeout: "20s"

[elasticmachine]

Pinging @elastic/kibana-security

[epixa]

@jkakavas @albertzaharovits This PR includes the functional token provider that'll depend on the token privileges from elastic/elasticsearch#35751.

[epixa]

cc @azasypkin

[epixa]

Super annoying, but the linter has a rule that disallows accessing static methods on BasicCredentials before it is defined in the same file. Even though it's all static. Dumb.

Anyway, I copied and pasted BasicCredentials without changes to the top of the file so linting would stop failing

[epixa]

If anyone wants to give this a whirl or provide any preliminary feedback, please do. It has no tests yet, so it's probably a little buggy, but it should be feature complete. I also haven't yet attempted to use both basic and token providers at the same time.

[epixa]

I discovered an unexpected behavior with this change where login attempts (and authorization header handling) are duplicated between token and basic providers when they are both enabled. I propose a solution to this problem by changing the way failures are handled in the authentication flow here: #26040

[epixa]

My proposed solution to the unexpected behavior in the auth provider failure logic was accepted, so I'm going to proceed with breaking this down and issuing more bite-sized (and tested) PRs.

I'm thinking in this order:

1. Change how failure works for providers
2. Add token APIs for elasticsearch-js
3. Overhaul login handling for basic provider with new login attempt service
4. Add token provider

[epixa]

The first three PRs are in, and the final PR that introduces the token provider itself is #26997. I'm going to close this prototype PR now.