fix(security, http): expose authentication headers in the authentication result when HTTP authentication is used #190998
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ion result when HTTP authentication is used
azasypkin
added
Team:Security
|
/ci |
💚 Build Succeeded
Metrics [docs]
To update your PR or re-run it, just comment with: cc @azasypkin |
|
Pinging @elastic/kibana-security (Team:Security) |
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Aug 22, 2024
…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)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
kibanamachine
added a commit
that referenced
this pull request
Aug 22, 2024
…entication result when HTTP authentication is used (#190998) (#191051) # 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)](#190998) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Aleh Zasypkin","email":"aleh.zasypkin@elastic.co"},"sourceCommit":{"committedDate":"2024-08-22T07:48:35Z","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/elastic/kibana/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/elastic/kibana/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/elastic/kibana/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/elastic/kibana/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/elastic/kibana/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--> Co-authored-by: Aleh Zasypkin <aleh.zasypkin@elastic.co>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
When Kibana tries to authenticate a request that already has an
Authorizationheader (not a cookie, client certificate, or Kerberos ticket), the authentication is performed by the HTTP authentication provider.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. TheAuthorizationheader is forwarded to Elasticsearch by default, no additional configuration is required.This worked well previously, but I think with the introduction of the the
getSecondaryAuthHeadersmethod 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.