Api token authc/z implementation with Cache #4992
Conversation
Signed-off-by: Derek Ho <[email protected]>
Signed-off-by: Derek Ho <[email protected]>
Signed-off-by: Derek Ho <[email protected]>
Signed-off-by: Derek Ho <[email protected]>
derek-ho
changed the title
Signed-off-by: Derek Ho <[email protected]>
…rmissions Signed-off-by: Derek Ho <[email protected]>
Signed-off-by: Derek Ho <[email protected]>
Signed-off-by: Derek Ho <[email protected]>
Signed-off-by: Derek Ho <[email protected]>
Signed-off-by: Derek Ho <[email protected]>
| originalSource = (new String(BaseEncoding.base64().decode((String) base64), StandardCharsets.UTF_8)); | ||
| } else { | ||
| originalSource = XContentHelper.convertToJson(originalResult.internalSourceRef(), false, XContentType.JSON); | ||
| if (originalSource == null) { |
There was a problem hiding this comment.
Changes in this file are to correct a mis-merge that happened in prior PRs to this feature branch.
Signed-off-by: Derek Ho <[email protected]>
derek-ho
requested review from
cwperks,
DarshitChanpura,
nibix,
peternied,
RyanL1997,
reta and
willyborankin
as code owners
derek-ho
changed the title
| * @param result The result of the index operation. | ||
| */ | ||
| @Override | ||
| public void postIndex(ShardId shardId, Engine.Index index, Engine.IndexResult result) { |
There was a problem hiding this comment.
Curious, why use this approach w/ IndexOperationListener opposed to the same approach as the security index vs in-memory data-structures that back the security index?
i.e. With the security index, if I call the API to create a new user. The node that receives the request will fulfill the request and add the new user to the security index. After updating the security index, it will use an internal transport action (TransportConfigUpdateAction) to instruct all nodes of the cluster to re-read from the security index. On node bootstrap, each node of the cluster reads from the security index and populates their in-memory cache of the security index.
| @@ -45,7 +46,7 @@ public class PrivilegesEvaluationContext { | |||
| private final IndexResolverReplacer indexResolverReplacer; | |||
| private final IndexNameExpressionResolver indexNameExpressionResolver; | |||
| private final Supplier<ClusterState> clusterStateSupplier; | |||
|
|
|||
| private final ApiTokenIndexListenerCache apiTokenIndexListenerCache = ApiTokenIndexListenerCache.getInstance(); | |||
There was a problem hiding this comment.
Why add this to PrivilegesEvaluatorContext?
I think this should be handled similarly to the security configCache from ConfigurationRepository: https://github.com/opensearch-project/security/blob/main/src/main/java/org/opensearch/security/configuration/ConfigurationRepository.java
There was a problem hiding this comment.
Note that security uses a publish-subscribe model to notify consumers about changes to the security config. See BackendRegistry.onDynamicConfigModelChanged for an example of a subscriber.
| @Test | ||
| public void testExtractCredentialsPassWhenJtiInCache() { | ||
| String testJti = | ||
| "eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJ0ZXN0LXRva2VuIiwiYXVkIjoidGVzdC10b2tlbiIsIm5iZiI6MTczNTMyNjM0NywiaXAiOiJnaGlWTXVnWlBtcHZJMjZIT2hmUTRnaEJ1Qkh0Y2x6c1REYVlxQjVBRklyTkE4SzJCVTdxc2toMVBCOEMzQWpTdVBaREM0THVSM2pjZkdpLzlkU2ZicDBuQTNGMkhtSi9jaDA3cDY2ZWJ6OD0iLCJpc3MiOiJvcGVuc2VhcmNoLWNsdXN0ZXIiLCJleHAiOjIyMTg3NjU2NDMzMCwiaWF0IjoxNzM1MzI2MzQ3LCJjcCI6IjlPS3N4aFRaZ1pmOVN1akprRzFXVWIzVC9RVTZ4YmZTc2hrbllkVUhraHM9In0.kqMSnn5YwhLmeiI_8iIBQ5uhmI52n2MNniAa52Zpfs3TiE_PXKiNbDNs08hNqzGYW772gT7lfvp6kZnFxQ4v2Q"; |
There was a problem hiding this comment.
Use Jwts.builder() to construct jwts for testing: https://github.com/opensearch-project/security/blob/main/src/main/java/org/opensearch/security/auth/BackendRegistry.java#L175-L193
Description
This PR implements authc/z for api tokens. For authc it is based on token validity for as well as presence in a cache, which listens to index and delete operations on the api token index. For Authz, it onboards onto action privileges class, where instead of returning not authorized for cluster and index privileges, requests go through a final api token check, where if the user is an api token, it will evaluate whether the permissions in the cache are sufficient to execute the request.
Issues Resolved
[List any issues this PR will resolve]
Is this a backport? If so, please add backport PR # and/or commits #, and remove
backport-failedlabel from the original PR.Do these changes introduce new permission(s) to be displayed in the static dropdown on the front-end? If so, please open a draft PR in the security dashboards plugin and link the draft PR here
Testing
[Please provide details of testing done: unit testing, integration testing and manual testing]
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.