Commits on Aug 22, 2024

1. fix(security, http): expose authentication headers in the authenticat… …

   …ion result when HTTP authentication is used (elastic#190998)
   
   ## Summary
   
   When Kibana tries to authenticate a request that already has an
   `Authorization` header (not a cookie, client certificate, or Kerberos
   ticket), the authentication is performed by the [HTTP authentication
   provider](https://www.elastic.co/guide/en/kibana/current/kibana-authentication.html#http-authentication).
   
   Unlike session/Kerberos/PKI providers, this provider returns an
   authentication result that doesn't explicitly tell Core which
   authorization headers should be used (e.g., `t.authenticated({ state:
   authenticationResult.user, --> requestHeaders:
   authenticationResult.authHeaders <-- ... });`), assuming that Core will
   just use the headers from the request. The `Authorization` header is
   forwarded to Elasticsearch by default, no additional configuration is
   required.
   
   This worked well previously, but I think with the introduction of the
   the
   [`getSecondaryAuthHeaders`](elastic#184901)
   method this is the first time where this assumption doesn't hold.
   Internally, this method tries to reuse authentication headers that were
   provided to Core by the authentication provider during the request
   authentication stage — headers that the HTTP authentication provider
   never provided before.
   
   This PR makes the HTTP authentication provider behave consistently with
   the rest of the providers we support today.
   
   (cherry picked from commit 3ac931f)

   

   azasypkin committed Aug 22, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 23081ed
   • Browse repository at this point

   Copy the full SHA

   23081ed View commit details

   Browse the repository at this point in the history