RANGER-5533:Verify JWT Issuer Claims if present

[ChinmayHegde24]

Support for validating the iss (issuer) claim in JWT has been added as part of this PR.

[kumaab]

Instead of adding a standalone validateIssuer() method, consider using Nimbus's DefaultJWTClaimsVerifier, which would consolidate issuer, audience, and expiration checks in one place:

JWTClaimsSet.Builder exactMatchBuilder = new JWTClaimsSet.Builder();
String               issuer            = config.getProperty(KEY_JWT_ISSUER);
if (StringUtils.isNotBlank(issuer)) {
    exactMatchBuilder.issuer(issuer);
}

Set<String> acceptedAudiences = null;
String      audiencesStr      = config.getProperty(KEY_JWT_AUDIENCES);
if (StringUtils.isNotBlank(audiencesStr)) {
    acceptedAudiences = new HashSet<>(Arrays.asList(audiencesStr.split(",")));
}

claimsVerifier = new DefaultJWTClaimsVerifier<>(acceptedAudiences, exactMatchBuilder.build(), null, null);
claimsVerifier.verify(jwtToken.getJWTClaimsSet(), null);

This would replace all three of validateExpiration(), validateAudiences(), and the proposed validateIssuer() with a single, well-tested library call. It also gets clock skew handling for free (the verifier has a configurable skew, defaulting to 60 seconds).

[ChinmayHegde24]

Current validateIssuer method can accept multiple issuers, but if we use DefaultJWTClaimsVerifier acceptance of single-issuer limitation comes , is that okay?

[kumaab]

Multi-issuer support is a good follow-up (in another PR). For this PR, I suggest to scope it for single-issuer validation. Multi-issuer support would require issuer-specific config and processor selection, something like:

jwt.issuers=issuerA,issuerB
jwt.issuer.issuerA.iss=https://idp-a/...
jwt.issuer.issuerA.jwks-url=...
jwt.issuer.issuerA.audiences=...
jwt.issuer.issuerB.iss=https://idp-b/...
jwt.issuer.issuerB.jwks-url=...
jwt.issuer.issuerB.audiences=...

so it would be better handled in a separate PR.

[ChinmayHegde24]

@kumaab Thank you for the suggestion.
I think it makes more sense to keep validateIssuer as a standalone method in this PR, and then replace all three methods together with a single DefaultJWTClaimsVerifier in a follow-up PR.

Handling the issuer claim with DefaultJWTClaimsVerifier here would introduce inconsistency, As the other validations are still separate and out of scope for this PR.
Please correct me if I'm wrong.

[ChinmayHegde24]

@kumaab Can you please check this