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.

Sign up for GitHub

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

Jump to bottom

Don't require cluster:admin/xpack/security/token/create privilege when client_credentials grant is used #41943

Closed
azasypkin opened this issue May 8, 2019 · 7 comments · Fixed by #42847
Closed

Don't require cluster:admin/xpack/security/token/create privilege when client_credentials grant is used #41943

azasypkin opened this issue May 8, 2019 · 7 comments · Fixed by #42847
Assignees
@bizybot @jkakavas
Labels
:Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc)

Comments

@azasypkin
Copy link
Member

azasypkin commented May 8, 2019 •
edited
Loading

As per Token Management API docs client_credentials grant type should allows us to create a token simply as the authenticated user (e.g. for Kerberos users when request to create a token would include Authorization: Negotiate **spnego-token** HTTP header), but currently Elasticsearch complains if user is not granted a cluster:admin/xpack/security/token/create cluster privilege.

Is it expected that all Kerberos users should be granted cluster:admin/xpack/security/token/create cluster privilege?

/cc @jkakavas @bizybot @kobelb
@azasypkin azasypkin added discuss :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) labels May 8, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security

@jkakavas
Copy link
Member

jkakavas commented May 8, 2019

A comment here for the required permissions with the current situation is that manage_token is not required, cluster:admin/xpack/security/token/create should be enough.

@jkakavas jkakavas mentioned this issue May 9, 2019
Merged
@azasypkin azasypkin changed the title Don't require manage_token cluster privilege when client_credentials grant is used Don't require cluster:admin/xpack/security/token/create privilege when client_credentials grant is used May 9, 2019
@azasypkin
Copy link
Member Author

Thanks @jkakavas! Updated title and description.

@tvernum
Copy link
Contributor

tvernum commented May 9, 2019

We discussed this and reached a general consensus that it would be better to introduce a kerberos-aware grant type that worked in the same manner as the password grant type (i.e. it runs under the kibana user & provides both access+refresh tokens), rather than trying to make client_credentials work for this use case.

@jkakavas & @bizybot will come up with a concrete proposal for that (at which point we can close this issue).

@azasypkin
Copy link
Member Author

Thanks for the update!

provides both access+refresh tokens

When we'll try to refresh such a token, will Elasticsearch check that Kerberos Ticket used to retrieve this access/refresh token pair is still valid as well?

@jkakavas
Copy link
Member

jkakavas commented May 9, 2019

When we'll try to refresh such a token, will Elasticsearch check that Kerberos Ticket used to retrieve this access/refresh token pair is still valid as well?

This needs to be discussed. Currently we do not support something similar in the TokenService and for SAML i.e. we do not take the time constraints that the IDP sets for the session into consideration after initial authentication.

@azasypkin
Copy link
Member Author

azasypkin commented May 9, 2019 •
edited
Loading

Got it, with client_credentials this would be implicitly enforced by Kibana - once token expires and there is no refresh token available we can't do anything other then to respond with 401 Authorization: Negotiate and get new (or cached) SPNEGO token from browser.

@bizybot bizybot mentioned this issue Jun 13, 2019
Merged
bizybot added a commit to bizybot/elasticsearch that referenced this issue Jun 18, 2019
@bizybot
Add kerberos grant_type to get token in exchange for Kerberos ticket (e…
4422c0e 
…lastic#42847)

Kibana wants to create access_token/refresh_token pair using Token
management APIs in exchange for kerberos tickets. `client_credentials`
grant_type requires every user to have `cluster:admin/xpack/security/token/create`
cluster privilege.

This commit introduces `_kerberos` grant_type for generating `access_token`
and `refresh_token` in exchange for a valid base64 encoded kerberos ticket.
In addition, `kibana_user` role now has cluster privilege to create tokens.
This allows Kibana to create access_token/refresh_token pair in exchange for
kerberos tickets.

Note:
The lifetime from the kerberos ticket is not used in ES and so even after it expires
the access_token/refresh_token pair will be valid. Care must be taken to invalidate
such tokens using token management APIs if required.

Closes elastic#41943
@bizybot bizybot mentioned this issue Jun 19, 2019
Merged
bizybot added a commit to bizybot/elasticsearch that referenced this issue Jun 19, 2019
@bizybot
Add kerberos grant_type to get token in exchange for Kerberos ticket (e…
9f9a2c3 
…lastic#42847)

Kibana wants to create access_token/refresh_token pair using Token
management APIs in exchange for kerberos tickets. `client_credentials`
grant_type requires every user to have `cluster:admin/xpack/security/token/create`
cluster privilege.

This commit introduces `_kerberos` grant_type for generating `access_token`
and `refresh_token` in exchange for a valid base64 encoded kerberos ticket.
In addition, `kibana_user` role now has cluster privilege to create tokens.
This allows Kibana to create access_token/refresh_token pair in exchange for
kerberos tickets.

Note:
The lifetime from the kerberos ticket is not used in ES and so even after it expires
the access_token/refresh_token pair will be valid. Care must be taken to invalidate
such tokens using token management APIs if required.

Closes elastic#41943
bizybot added a commit that referenced this issue Jun 19, 2019
@bizybot
Add kerberos grant_type to get token in exchange for Kerberos ticket (#…
2f17340 
…42847) (#43355)

Kibana wants to create access_token/refresh_token pair using Token
management APIs in exchange for kerberos tickets. `client_credentials`
grant_type requires every user to have `cluster:admin/xpack/security/token/create`
cluster privilege.

This commit introduces `_kerberos` grant_type for generating `access_token`
and `refresh_token` in exchange for a valid base64 encoded kerberos ticket.
In addition, `kibana_user` role now has cluster privilege to create tokens.
This allows Kibana to create access_token/refresh_token pair in exchange for
kerberos tickets.

Note:
The lifetime from the kerberos ticket is not used in ES and so even after it expires
the access_token/refresh_token pair will be valid. Care must be taken to invalidate
such tokens using token management APIs if required.

Closes #41943
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bizybot bizybot

@jkakavas jkakavas

Labels
:Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc)
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add kerberos grant_type to get token in exchange for Kerberos ticket bizybot/elasticsearch
5 participants
@bizybot @azasypkin @tvernum @jkakavas @elasticmachine