8000 Changes required to support JWT tokens (CADC-14107) by andamian · Pull Request #269 · opencadc/core · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Changes required to support JWT tokens (CADC-14107) #269

New issue 8000

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

andamian
Copy link
Contributor
@andamian andamian commented Jun 12, 2025

Used in opencadc/ac#179

@andamian andamian marked this pull request as ready for review June 27, 2025 21:49
@@ -248,6 +248,25 @@ private static StringBuilder getContent(SignedToken token) {
return sb;
}

/**
* Checks whether a token is a CADC access token or not
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"a CADC access token" -> SignedToken

also, Base64.decodeString(String) exists and could be used instead of new String... it's the same code but intended for this use case

should be catch(IllegalArgumentException ignore)

Q. Why does this handle plain text and base64-encoded test? And why is the condition different in those two cases? Aren't all SignedToken values in headers base64 encoded?

@@ -149,11 +149,14 @@ public static Subject validateTokens(Subject subject) throws NotAuthenticatedExc
log.debug("credentials: " + credentials);

try {
if (!SignedToken.isSignedToken(credentials)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The logic in validateTokens could be simplified:

  1. remove the initial if(AuthenticationUtil.TOKEN_TYPE_CADC bit entirely (and remove the deprecated constants in AuthenticationUtil and all use of them)
  2. the if (AuthenticationUtil.AUTHORIZATION_HEADER part of where we look for SignedTokens, but now that we're only looking for one form, I would consolidate this with the subsequent if like this:
if (AuthenticationUtil.AUTHORIZATION_HEADER.equals(p.getHeaderKey())) {
    // split on space(s) and trim
    String challenge = ...
    String credentials = ...
    if (SignedToken.isSignedToken(credentials) {
        SignedToken validatedToken = SignedToken.parse(credentials);
        ...
    } // else: some other kind of bearer token: leave AuthorizationTokenPrincipal for additional processing
}

@@ -776,6 +776,9 @@ public static String getPrincipalType(Principal userID) {
if (userID instanceof X500Principal) {
return IdentityType.X500.getValue().toLowerCase();
}
if (userID instanceof OpenIdPrincipal) {
return ((OpenIdPrincipal)userID).getIssuer().toExternalForm();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recall discussing the API to /ac/users/{value}?idType={type} and that we could do this for OpenID:

/ac/users/{sub}?iss={issuer}

So I don't see why we want to have this misleading/incorrect treatment of the issuer as a type???

the AC specific code (ACIdentityManager only?) that knows about this should treat OpenIDPrincipal explicitly and call getIssuer() itself to match the query param is is going to use... or is there some reason that you think that API should really use type as the param?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0