[FEATURE REQUEST] AadJwtBearerTokenAuthenticationConverter Change In Public Methods

[azizabah]

Describe the bug
When upgrading from Azure Spring BOM 3.6.0 to 4.0.0, the exposed methods on AadJwtBearerTokenAuthenticationConverter (in addition to the AAD to Aad in the name) have changed. Specifically, we used this method historically to set a custom implementation that extended AadJwtGrantedAuthoritiesConverter.

 public void setJwtGrantedAuthoritiesConverter(
        Converter<Jwt, Collection<GrantedAuthority>> jwtGrantedAuthoritiesConverter) {
        this.jwtGrantedAuthoritiesConverter = jwtGrantedAuthoritiesConverter;
    }

To the best of my knowledge, I am not seeing an equivalent in the exposed constructors or existing methods here: https://github.com/Azure/azure-sdk-for-java/blob/c95ee077372865664baf2f9eec7e55397ec09b84/sdk/spring/spring-cloud-azure-autoconfigure/src/main/java/com/azure/spring/cloud/autoconfigure/aad/AadJwtBearerTokenAuthenticationConverter.java

Expected behavior
We should be able to set a custom JwtGrantedAuthoritiesConverter. Right now it is hardcoded by this line of code:

azure-sdk-for-java/sdk/spring/spring-cloud-azure-autoconfigure/src/main/java/com/azure/spring/cloud/autoconfigure/aad/AadJwtBearerTokenAuthenticationConverter.java

Line 70 in c95ee07

this.converter = new AadJwtGrantedAuthoritiesConverter(claimToAuthorityPrefixMap);

If you suspect a dependency version mismatch (e.g. you see NoClassDefFoundError, NoSuchMethodError or similar), please check out Troubleshoot dependency version conflict article first. If it doesn't provide solution for the problem, please provide:

• verbose dependency tree (mvn dependency:tree -Dverbose)
• exception message, full stack trace, and any available logs

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• Bug Description Added
• Repro Steps Added
• Setup information Added

[chenrujun]

Hi, @azizabah . Thanks for reaching out.

1. What is your customized jwtGrantedAuthoritiesConverter like?
2. Is it possible to use AadJwtBearerTokenAuthenticationConverter(String principalClaimName, Map<String, String> claimToAuthorityPrefixMap) instead of setJwtGrantedAuthoritiesConverter(...) to satisfy your requirement?
3. Maybe you can try this workaround before this issue resolved: Write your own JwtBearerTokenAuthenticationConverter by extending AadJwtBearerTokenAuthenticationConverter or Converter<Jwt, AbstractAuthenticationToken>. Then use the converter in your WebSecurityConfigurerAdapter just like AadResourceServerWebSecurityConfigurerAdapter did.

[azizabah]

Thanks for taking a look, @chenrujun .

1. Effectively it converts the JWT using AadJwtGrantedAuthoritiesConverter. It then has some business logic to add additional grants based on internal business logic to determine the userPrincipal and then a call to an internal service for users' permissions. It then concatenates the original Collection from the super.convert(jwt) with our added ones from the internal service call.
2. Not in any way that's readily obvious to me.
3. That's exactly what we did before the contract was broken. We have a CustomJwtAuthenticationConverter that extends AadJwtBearerTokenAuthenticationConverter and a CustomGrantedAuthoritiesConverter that extends AadJwtGrantedAuthoritiesConverter and we set the JwtGrantedAuthoritiesConverter on the CustomJwtAuthenticationConverter to the CustomGrantedAuthoritiesConverter. We then set that as the jwtAuthenticationConverter on a class that extends AadResourceServerWebSecurityConfigurerAdapter.

Looking at AadJwtBearerTokenAuthenticationConverter, I will have to effectively copy + paste the convert method into our class, override it, and then add in the missing logic. This is bad because now we need to be aware of any changes in that class' method and incorporate those into our duplicate code just because the contract was broken.