Properly handle password change for users authenticated with provider other than basic.#55206
Conversation
|
Pinging @elastic/kibana-security (Team:Security) |
17bd25c to
516cb45
Compare
There was a problem hiding this comment.
note: these changes aren't mandatory, just forgot to remove this cleanup. For the majority of places I tried to not change anything.
There was a problem hiding this comment.
note: for BWC reasons kept legacy API async.
There was a problem hiding this comment.
note: reducing API surface. This workaround was introduced exactly for this use case and we don't need it anymore.
There was a problem hiding this comment.
note: couldn't find a better way :/
There was a problem hiding this comment.
I'm not aware of any other way to get access to a static property from an instance... The only other option that comes to mind is not making getUser return the AuthenticatedUser model, and instead return an interface which doesn't include the authentication_provider field. The authenticator itself could then add the provider which was used, and everything else could continue to use the AuthenticatedUser`.
There was a problem hiding this comment.
Yeah, that would be an option too, the tricky thing here is that AuthenticationResult.user that providers return is AuthenticatedUser and we rely on this fact in some other places... I tend to keep what I have for the time being and see how it goes.
There was a problem hiding this comment.
note: we didn't handle the case without session previously, but I think it was a bug. And now we have a proper API that can tell us if we have an active session or not.
…hentication provider.
516cb45 to
210cb67
Compare
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
|
ACK: reviewing |
There was a problem hiding this comment.
I'm not aware of any other way to get access to a static property from an instance... The only other option that comes to mind is not making getUser return the AuthenticatedUser model, and instead return an interface which doesn't include the authentication_provider field. The authenticator itself could then add the provider which was used, and everything else could continue to use the AuthenticatedUser`.
* master: (23 commits) Properly handle password change for users authenticated with provider other than `basic`. (elastic#55206) Improve pull request template proposal (elastic#56756) Only change handlers as the element changes (elastic#56782) [SIEM][Detection Engine] Final final rule changes (elastic#56806) [SIEM][Detection Engine] critical blocker, wrong ilm policy, need to match beats ilm policy Move ui/agg_types in to shim data plugin (elastic#56353) [SIEM] Fixes Signals count spinner (elastic#56797) [docs] Update upgrade version path (elastic#56658) [Canvas] Use unique Id for Canvas Embeddables (elastic#56783) [Rollups] Adjust max width for job detail panel (elastic#56674) Prevent http client from converting our form data (elastic#56772) Disable creating alerts client instances when ESO plugin is using an ephemeral encryption key (elastic#56676) Bumps terser-webpack-plugin to 2.3.4 (elastic#56662) Advanced settings component registry ⇒ kibana platform plugin (elastic#55940) [Endpoint] EMT-67: add kql support for endpoint list (elastic#56328) Implement UI for Create Alert form (elastic#55232) Fix: Filter pill base coloring (elastic#56761) fix open close signal on detail page (elastic#56757) [Search service] Move loadingCount to sync search strategy (elastic#56335) Rollup TSVB integration: Add test and fix warning text (elastic#56639) ...
|
7.x/7.7.0: 20b3db1 |
In this PR we're starting to do a couple of things differently:
We record the type of authentication provider used to authenticated user in the instance of
AuthenticatedUserwe hand over to the Core inhttp.registerAuthhook handler.We switch implementation of
getCurrentUserandisAuthenticatedto useAuthStatecreated during request authentication stage (yet to be exposed by the core in the scope of Expose Core's Auth State API to the plugins #55011). The methods become synchronous as the result.We no longer hard code authentication provider type when we re-login user after they change their own password. Now we just use the same provider that was used to authenticate original request.
We no longer try to re-login if user that changed their own password didn't have an active session.
I dropped redundant "stateless" login API that was introduced previously for the related use case.
If user is changing their own password we always send request to Elasticsearch with
Authorization: Basic base64(username:current_password)no matter which provider was used to authenticate user. This is required since user must provide a proof of knowledge of the current password.Blocked by: #55011Fixes: #49865