Upgrading azure-spring-boot-starter-active-directory to obtain AD user roles

I'm looking for some help moving from azure-active-directory-spring-boot-starter 2.3.5 to the latest version azure-spring-boot-starter-active-directory 3.6.1.

Our current use case is a user logs into a web application using AAD. The web application contacts a back end Spring Boot application with a JWT in the request containing user data. We use a PreAuthorise annotation to send the request to an AADAuthenticationFilter via a SecurityChain. The filter deciphers the JWT, contacts Microsoft Graph API, checks the user has a user role with a declared prefix ('A1' in the example code below) and if so adds the users AAD user roles to the request which is then returned. This works fine with azure-active-directory-spring-boot-starter 2.3.5 however there's been some breaking changes when we try to upgrade to 3.6.1 including the AADAuthenticationFilter class now being deprecated. We need to upgrade to remove some dependency vulnerabilities version 2.3.5 has.

It's worth mentioning the current solution we use is slightly modified to allow us to check the user role starts with the declared prefix. We used the answer from Spring Security and Azure: is there a Active Directory group wildcard? to implement this.

@PreAuthorize("@RoleCheck.roleHasPrefix(#req, 'ROLE_A1-')")
@CrossOrigin
@GetMapping(path = "/myPermissions", produces = APPLICATION_JSON_VALUE)
public List<Permission> myPermissions(@Context HttpServletRequest req){
    return permHelper.getUserPermissions(permHelper.getAuthorities(req));
} 

Security config

@EnableGlobalMethodSecurity(securedEnabled = true,
        prePostEnabled = true)
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    
    @Autowired
    private A1AADAuthenticationFilter aadAuthFilter;

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        
        http.cors().and().authorizeRequests().anyRequest().permitAll().and().csrf().disable();
        http.addFilterBefore(aadAuthFilter, UsernamePasswordAuthenticationFilter.class);
        
    }
} 

When upgrading to 3.6.1, packages have been changed and certain classes no longer exist such as ServiceEndpointsProperties, if we try to implement the old solution that is currently working we consistently get null pointer exceptions as we're unable to inject certain classes. We would have to copy and modify a number of classes from the api to get the app to possibly start up which wouldn't be practical.

If we use the deprecated AADAuthenticationFilter that comes with the API then the check for the prefix no longer works, we get the error below.

c.a.s.a.aad.AADAuthenticationFilter      : Request token verification success. org.springframework.security.web.authentication.preauth.PreAuthenticatedAuthenticationToken@40dfe192: Principal: com.azure.spring.autoconfigure.aad.UserPrincipal@4c2e3a2; Credentials: [PROTECTED]; Authenticated: true; Details: null; Granted Authorities: ROLE_USER

We can get it working if we ignore the prefix and explicitly declare which user roles are allowed via the property 'azure.activedirectory.user-group.allowed-group-names' however this isn't very practical for us as new user roles are frequently added. We would be happy returning every role the user has and filtering ourselves in the back end which we have tried by using the properties:

• azure.activedirectory.user-group.allowed-group-ids:all
• azure.activedirectory.user-group.enable-full-list:true

However this again gives the error:

c.a.s.a.aad.AADAuthenticationFilter      : Request token verification success. org.springframework.security.web.authentication.preauth.PreAuthenticatedAuthenticationToken@40dfe192: Principal: com.azure.spring.autoconfigure.aad.UserPrincipal@4c2e3a2; Credentials: [PROTECTED]; Authenticated: true; Details: null; Granted Authorities: ROLE_USER

Any help you can provide we would be grateful, ideally we would like to still check the prefix first however if that isn't possible then we're happy to return all of the user roles and we can write code later to filter them. It's a shame the property 'azure.activedirectory.user-group.allowed-group-names' doesn't accept wildcards so we could enter the prefix there.