[8.15] fix(security, http): expose authentication headers in the authentication result when HTTP authentication is used (#190998)

[kibanamachine]

Backport

This will backport the following commits from main to 8.15:

• fix(security, http): expose authentication headers in the authentication result when HTTP authentication is used (#190998)

Questions ?

Please refer to the Backport tool documentation

requestHeaders:\r\nauthenticationResult.authHeaders <-- ... });`), assuming that Core will\r\njust use the headers from the request. The `Authorization` header is\r\nforwarded to Elasticsearch by default, no additional configuration is\r\nrequired.\r\n\r\nThis worked well previously, but I think with the introduction of the\r\nthe\r\n[`getSecondaryAuthHeaders`](https://github.com//pull/184901)\r\nmethod this is the first time where this assumption doesn't hold.\r\nInternally, this method tries to reuse authentication headers that were\r\nprovided to Core by the authentication provider during the request\r\nauthentication stage — headers that the HTTP authentication provider\r\nnever provided before.\r\n\r\nThis PR makes the HTTP authentication provider behave consistently with\r\nthe rest of the providers we support today.","sha":"3ac931fb796b2053c68b454804e643788dc598d9","branchLabelMapping":{"^v8.16.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Security","release_note:skip","backport:prev-minor","v8.16.0"],"title":"fix(security, http): expose authentication headers in the authentication result when HTTP authentication is used","number":190998,"url":"https://github.com//pull/190998","mergeCommit":{"message":"fix(security, http): expose authentication headers in the authentication result when HTTP authentication is used (#190998)\n\n## Summary\r\n\r\nWhen Kibana tries to authenticate a request that already has an\r\n`Authorization` header (not a cookie, client certificate, or Kerberos\r\nticket), the authentication is performed by the [HTTP authentication\r\nprovider](https://www.elastic.co/guide/en/kibana/current/kibana-authentication.html#http-authentication).\r\n\r\nUnlike session/Kerberos/PKI providers, this provider returns an\r\nauthentication result that doesn't explicitly tell Core which\r\nauthorization headers should be used (e.g., `t.authenticated({ state:\r\nauthenticationResult.user, --> requestHeaders:\r\nauthenticationResult.authHeaders <-- ... });`), assuming that Core will\r\njust use the headers from the request. The `Authorization` header is\r\nforwarded to Elasticsearch by default, no additional configuration is\r\nrequired.\r\n\r\nThis worked well previously, but I think with the introduction of the\r\nthe\r\n[`getSecondaryAuthHeaders`](https://github.com//pull/184901)\r\nmethod this is the first time where this assumption doesn't hold.\r\nInternally, this method tries to reuse authentication headers that were\r\nprovided to Core by the authentication provider during the request\r\nauthentication stage — headers that the HTTP authentication provider\r\nnever provided before.\r\n\r\nThis PR makes the HTTP authentication provider behave consistently with\r\nthe rest of the providers we support today.","sha":"3ac931fb796b2053c68b454804e643788dc598d9"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com//pull/190998","number":190998,"mergeCommit":{"message":"fix(security, http): expose authentication headers in the authentication result when HTTP authentication is used (#190998)\n\n## Summary\r\n\r\nWhen Kibana tries to authenticate a request that already has an\r\n`Authorization` header (not a cookie, client certificate, or Kerberos\r\nticket), the authentication is performed by the [HTTP authentication\r\nprovider](https://www.elastic.co/guide/en/kibana/current/kibana-authentication.html#http-authentication).\r\n\r\nUnlike session/Kerberos/PKI providers, this provider returns an\r\nauthentication result that doesn't explicitly tell Core which\r\nauthorization headers should be used (e.g., `t.authenticated({ state:\r\nauthenticationResult.user, --> requestHeaders:\r\nauthenticationResult.authHeaders <-- ... });`), assuming that Core will\r\njust use the headers from the request. The `Authorization` header is\r\nforwarded to Elasticsearch by default, no additional configuration is\r\nrequired.\r\n\r\nThis worked well previously, but I think with the introduction of the\r\nthe\r\n[`getSecondaryAuthHeaders`](https://github.com//pull/184901)\r\nmethod this is the first time where this assumption doesn't hold.\r\nInternally, this method tries to reuse authentication headers that were\r\nprovided to Core by the authentication provider during the request\r\nauthentication stage — headers that the HTTP authentication provider\r\nnever provided before.\r\n\r\nThis PR makes the HTTP authentication provider behave consistently with\r\nthe rest of the providers we support today.","sha":"3ac931fb796b2053c68b454804e643788dc598d9"}}]}] BACKPORT-->

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 23081ed

Failed CI Steps

Metrics [docs]

✅ unchanged

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @azasypkin