Implement lookup of permissions for API keys#35970
Implement lookup of permissions for API keys#35970jaymode merged 11 commits intoelastic:security_api_keysfrom
Conversation
This change implements a lookup of permissions for API keys when a request moves to authorization. In order to support this, the authentication of an API key will attach values as metadata on the authentication result. The values attached will include the source of the role descriptors. The authentication service will then copy this metadata to the authentication object and set the authentication type to API_KEY. The authorization service will use the authentication type to make a decision on how the roles should be obtained.
jaymode
added
>non-issue
WIP
:Security/Authentication
|
Pinging @elastic/es-security |
tvernum
left a comment
tvernum
left a comment
There was a problem hiding this comment.
I much prefer this approach to the one that created named roles.
x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/ApiKeyService.java
Outdated
Show resolved
Hide resolved
| public enum AuthenticationType { | ||
| REALM, | ||
| API_KEY, | ||
| TOKEN |
There was a problem hiding this comment.
Is it worth adding ANONYMOUS as an option here?
I think the current behaviour will treat it as REALM which isn't quite right.
Happy to see it in a follow up PR.
There was a problem hiding this comment.
Yeah it is. I think there can be some other values as well. Will address in a followup
bizybot
left a comment
bizybot
left a comment
There was a problem hiding this comment.
LGTM, had a comment on the caching of role which if desirable we can do it in next PRs. Thank you.
|
|
||
| rolesStore.buildRoleFromDescriptors(roleDescriptorList, fieldPermissionsCache, ActionListener.wrap(role -> { | ||
| threadContext.putTransient(API_KEY_ID_KEY, apiKeyId); | ||
| threadContext.putTransient(API_KEY_ROLE_KEY, role); |
There was a problem hiding this comment.
I see this as caching the built role similar to what we do in CompositeRolesStore (roleCache where we cache the role against the set of role names). But here we are keeping it in the ThreadContext as transient, I was wondering if it would be helpful to or desirable to have a cache similar to what we have in CompositeRolesStore?
We can enhance this if required in next PRs.
There was a problem hiding this comment.
As we discussed, this is not equivalent to caching and caching is superior so we'll want to do that.
This change builds upon the work done in elastic#35970 and adds appropriate types for anonymous and internal authentication to the `AuthenticationType` enum.
This change builds upon the work done in #35970 and adds appropriate types for anonymous and internal authentication to the `AuthenticationType` enum.
4 participants
This change implements a lookup of permissions for API keys when a
request moves to authorization. In order to support this, the
authentication of an API key will attach values as metadata on the
authentication result. The values attached will include the source
of the role descriptors. The authentication service will then copy
this metadata to the authentication object and set the authentication
type to API_KEY. The authorization service will use the authentication
type to make a decision on how the roles should be obtained.