[Feature/Extension] Extension token handler#3034
[Feature/Extension] Extension token handler#3034RyanL1997 wants to merge 6 commits intoopensearch-project:feature/extensionsfrom
Conversation
Codecov Report
@@ Coverage Diff @@
## feature/extensions #3034 +/- ##
========================================================
- Coverage 62.38% 5.47% -56.92%
+ Complexity 3390 222 -3168
========================================================
Files 259 275 +16
Lines 20044 20198 +154
Branches 3371 3392 +21
========================================================
- Hits 12505 1105 -11400
- Misses 5888 18913 +13025
+ Partials 1651 180 -1471
|
358fe72 to
d6c541e
Compare
|
Moving some of the communication between me and @scrawfor99 over here
|
RyanL1997
left a comment
There was a problem hiding this comment.
Adding some additional context here:
| return (exp > currentTime && !revokedTokens.exists(bearerAuthToken.getCompleteToken())); | ||
| } | ||
|
|
||
| public boolean validateJustInTimeToken(AuthToken authToken) { |
There was a problem hiding this comment.
The reason I make this validation is that I think we do have different expectations for obo tokens than the other bearer auth tokens. For obo tokens, according to its feature of just-in-time, we do expect the payload of iat and nbf have the same value.
| JwtClaims jwtClaims = new JwtClaims(); | ||
| JwtToken jwt = new JwtToken(jwtClaims); | ||
|
|
||
| jwtClaims.setProperty("typ", tokenIdentifier); |
There was a problem hiding this comment.
This is the idea that can be also applied for the potential approach of handling the edge cases of OBO endpoint (see comments). By having a token type as the identifier, it will be easier for us to know if it is a obo token or not so that we can have different expectations.
If we decide to go with this design, I will also update the threat model documentation
| Long iat = (Long) jwt.getClaim("iat"); | ||
| Long nbf = (Long) jwt.getClaim("nbf"); | ||
| Long exp = (Long) jwt.getClaim("exp"); | ||
| SecurityDynamicConfiguration revokedTokens = load(getRevokedTokensConfigName(), false); |
There was a problem hiding this comment.
If we choose to split the validations between obo tokens and other bearer auth tokens in this way, then I don't think we need this line here, since the revocation is not in the scope of obo token. (At least for now)
cwperks
left a comment
There was a problem hiding this comment.
@RyanL1997 There looks to be a lot more on this PR than an implementation of issueOnBehalfOfToken. Is everything in this PR needed for the issuance of obo tokens? Can we narrow the PR to the issuance of obo tokens and have a subsequent PR address the issuance of service account tokens?
| List<String> roles, | ||
| List<String> backendRoles | ||
| ) throws Exception { | ||
| String tokenIdentifier = "obo"; |
There was a problem hiding this comment.
Can this variable be called tokenType?
Sometimes JWTs include a claim called jti that is a unique identifier for a token. In my experience, systems use jti to invalidate tokens since this identifier uniquely identifies a token.
|
|
||
| import static org.opensearch.security.dlic.rest.support.Utils.universalHash; | ||
|
|
||
| public class InternalUserTokenHandler implements TokenManager { |
There was a problem hiding this comment.
This class looks like its doing too much. In the PR description it mentions that this PR is for issueOnBehalfOfToken. Are all of these methods being utilized in this class?
Signed-off-by: Ryan Liang <jiallian@amazon.com>
Signed-off-by: Ryan Liang <jiallian@amazon.com>
Signed-off-by: Ryan Liang <jiallian@amazon.com>
Signed-off-by: Ryan Liang <jiallian@amazon.com>
Signed-off-by: Ryan Liang <jiallian@amazon.com>
ef2e39d to
69dfb67
Compare
Signed-off-by: Ryan Liang <jiallian@amazon.com>
| public static DiscoveryNode getLocalNode() { | ||
| return localNode; | ||
| } | ||
|
|
||
| public static void setLocalNode(DiscoveryNode node) { | ||
| localNode = node; | ||
| } |
There was a problem hiding this comment.
this should be removed. Check this PR for more details: https://github.com/opensearch-project/security/pull/3066/files
| return; | ||
| } catch (IOException ex) { | ||
| throw new IOException(ex); | ||
| } catch (NoSuchAlgorithmException e) { |
There was a problem hiding this comment.
Why add this catch block to then throw RuntimeException?
| @Subscribe | ||
| public void onDynamicConfigModelChanged(DynamicConfigModel dcm) { | ||
| this.dcm = dcm; | ||
| if (dcm.getDynamicOnBehalfOfSettings().get("signing_key") != null |
There was a problem hiding this comment.
we should extract: dcm.getDynamicOnBehalfOfSettings() to a variable
|
|
||
| return passwordGenerator.generatePassword(random.nextInt(8) + 8, rules); | ||
| private String generatePassword() { | ||
| return "superSecurePassword"; |
| import java.io.IOException; | ||
| import java.util.Collections; | ||
|
|
||
| public class UserTokenHandler { |
There was a problem hiding this comment.
Is this class different that InternalUserTokenHandler in the sense that this class deals with actual user vs the other one deals with service accounts?
If so why not combine them into 1 class?
| claims = new HashMap<String, Object>() { | ||
| { | ||
| put(JwtConstants.CLAIM_AUDIENCE, "ext_0"); | ||
| } | ||
| }; |
There was a problem hiding this comment.
can write this as: Map.of(JwtConstants.CLAIM_AUDIENCE, "ext_0");
Description
This PR is the refactor/modification based on @scrawfor99's previous PR(#2787) against main branch for Extension token handler. However, the scope of this PR is only for OBO related changes.
New Feature
Issues Resolved
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.