Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose Core's Auth State API to the plugins #55011

Closed
azasypkin opened this issue Jan 16, 2020 · 2 comments · Fixed by #55327
Closed

Expose Core's Auth State API to the plugins #55011

azasypkin opened this issue Jan 16, 2020 · 2 comments · Fixed by #55327
Assignees
Labels
blocker Feature:New Feature New feature not correlating to an existing feature label Feature:New Platform Feature:Security/Authentication Platform Security - Authentication Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!

Comments

@azasypkin
Copy link
Member

Currently Core stores authentication state (user information) returned from the http.registerAuth hook handler internally and hence it's not available to plugins even to the Security plugin that created the state.

It means that Security plugin should always do additional call to /_security/_authenticate if it wants to get currently authenticated user even though this information is already stored in the core, but just not available to us.

But more importantly during request authentication stage Security would like to store additional Kibana specific information that can't be retrieved from /_security/_authenticate afterwards, e.g. the name/type of the authentication provider that was used to authenticate request (needed for #49865 and potentially for #39313).

This type of information is already available through public Security API so we're not exposing anything extra here.

Ideally Security would like to have access to the state itself and whether or not request was successfully authenticated. That would help us to eliminate unnecessary back-end calls and pave the way to solving more use cases.

@azasypkin azasypkin added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Feature:New Platform Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! Feature:Security/Authentication Platform Security - Authentication Feature:New Feature New feature not correlating to an existing feature label labels Jan 16, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-security (Team:Security)

@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-platform (Team:Platform)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocker Feature:New Feature New feature not correlating to an existing feature label Feature:New Platform Feature:Security/Authentication Platform Security - Authentication Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants