damienburke commented on code in PR #22215:
URL: https://github.com/apache/pulsar/pull/22215#discussion_r1517489342


##########
pulsar-broker-common/src/main/java/org/apache/pulsar/broker/authentication/AuthenticationProviderToken.java:
##########
@@ -458,4 +485,64 @@ public String getHeader(String name) {
             return super.getHeader(name);
         }
     }
+
+    @Slf4j
+    private static final class JwkResolver implements SigningKeyResolver {
+        @Setter
+        @Getter
+        private static class JwksData {
+            private List<Map<String, Object>> keys;
+        }
+
+        private final Map<String, Jwk> jwks;
+
+        public JwkResolver(String configValue) {
+            try {
+                byte[] bytes = AuthTokenUtils.readKeyFromUrl(configValue);
+                ObjectMapper objectMapper = ObjectMapperFactory.create();
+                JwksData data = objectMapper.reader().readValue(bytes, 
JwksData.class);
+                if (data == null || data.getKeys() == null || 
data.getKeys().isEmpty()) {
+                    log.warn("No keys in " + data);
+                    jwks = Collections.emptyMap();
+                    return;
+                }
+                jwks = new LinkedHashMap<>();
+                data.getKeys().forEach((n) -> {
+                    Jwk jwk = Jwk.fromValues(n);
+                    jwks.put(jwk.getId(), jwk);
+                });
+                if (log.isDebugEnabled()) {
+                    log.info("jwks: {}", jwks);
+                }
+            } catch (IOException e) {
+                log.error("Failed to get jwks from {}", configValue, e);
+                throw new IllegalArgumentException(e);
+            }
+        }
+
+        private Key get(String keyId) {

Review Comment:
   > If the kid is null, and you only have one key in the JWKS file, we can use 
this key to verify your token.
   
   While that would be correct - to support migrating from a single non-kid key 
to kid keys.. the JWKS file would need to store both. This general approach is 
perhaps cleaner / less confusing though than what i proposed. Specifically, the 
existing, single key config and this new JWKS config can remain separate (and u 
set one or the other).     
   
   So to support the migration use case  we could introduce a new optional 
field into the `JwkResolver` - lets calls it `legacyKey` for now. This field 
would be set when the `JwkResolver` is spinning through the file, and if it 
sees an entry with no kid, it sets the `legacyKey` field only. Finally, we just 
update the Key get(String keyId) to return this `legacyKey` field if the 
incoming JWT has no kid.  



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to