Use configured `GrantedAuthoritiesMapper` when parsing `@WithMockKeycloakAuth` realm and resource-access roles about spring-addons

[ch4mpy]

No, it shouldn't. Prefixing authorities with ROLE_ is an implementation choice inside authorities mappers and authorities in test annotations are designed to hold already mapped authorities (mappers can make any kind of transformation).

At some point, both authorities and roles where exposed in my test annotations, the second adding the ROLE_ prefix. This was leading to more confusion than help and I removed the less generic one (couldn't make authorities with other prefix or no prefix at all with roles)

[schmitzhermes]

Hmm, I agree that this is an implementation choice inside the mappers, but this choice only needs to be made because Spring Boot made the choice to have ROLE_ as the default prefix (if not configured otherwise), as can be seen here ExpressionUrlAuthorizationConfigurer.java#L116.

Maybe it's just my opinion but as this is a library that enhances SPRING, it'd be absolutely sane to apply the spring boot defaults (like ROLE_) and let people override them if they want.

Of course one can override the default prefix in Spring Boot using something like below, but again: it does not feel natural to alter working production code in order to make test working more seamlessly.

@Bean
    fun grantedAuthorityDefaults(): GrantedAuthorityDefaults {
        return GrantedAuthorityDefaults("YOUR_PREFIX")
    }

[ch4mpy]

Maybe should I remove completely realm and resource access roles adding to authorities to avoid confusion.

You need certain authorities with prefix, suffix, case tweeking or wahtever in a test? Put it like it needs to be in authorities property. It's made for that.

Any spring-boot application explicitely providing a GrantedAuthoritiesMapper bean can do about anything with authorities and test annotation can hardly figure out what. Most production spring-boot apps I know configure such a bean.

If you take a look into spring-security-core org.springframework.security.core.authority.mapping package you'll see that:

• SimpleAuthorityMapper does add ROLE_ prefix
• NullAuthoritiesMapper doesn't

Maybe are you using hasRole or hasAnyRole rather than hasAuthority or hasAnyAuthority to think that "ROLE_" prefix is a convention?

[ch4mpy]

Anyhow, I'll try to see if I can detect a GrantedAuthoritiesMapper @Bean in test configuration and use it when extracting Keycloak roles, but not today.

[schmitzhermes]

Okay, I do get your point and I also agree (though not wholeheartedly 😄 )
Thanks for looking into it and thank you for the productive discussion and blazingly fast response - this is open source spirit!!

[schmitzhermes]

Maybe are you using hasRole or hasAnyRole rather than hasAuthority or hasAnyAuthority to think that "ROLE_" prefix is a convention?

Yes, I do. My security configuration relies on hasRole instead of hasAuthority and the hasRole convenience method adds the ROLE_ prefix. But I understand that there are other "authorities" than roles.

But I can also live with the "configure authorities as Spring Boot would" and you are happy in tests. 👍

[ch4mpy]

So looking a little further, configured GrantedAuthoritiesMapper is already injected and if something else than NullAuthorityMapper is configured, it should process authorities.

Can you provide me with your Keycloak configuration?

By the way, my very simple Keycloak spring-boot conf does not alter roles

[schmitzhermes]

Okay, I got it now:

• As I am using the hasRole(...) function Spring Boot appends ROLE_ in the SpEL while assessing the roles
• Therefore I needed to configure the SimpleAuthorityMapper in my Keycloak configuration
• Your library expects a GrantedAuthoritiesMapper to be injected, however imho it's normally not injected, but rather instantiated in place like so:

@KeycloakConfiguration
@EnableGlobalMethodSecurity(prePostEnabled = true)
class KeycloakSecurityConfiguration : KeycloakWebSecurityConfigurerAdapter() {
    // .. other config
    
    @Autowired
    fun configureGlobal(auth: AuthenticationManagerBuilder) {
        val keycloakAuthenticationProvider = keycloakAuthenticationProvider()
        keycloakAuthenticationProvider.setGrantedAuthoritiesMapper(SimpleAuthorityMapper())
        auth.authenticationProvider(keycloakAuthenticationProvider)
    }
}

• This leads to your library not finding the bean and thus, not injecting it

There are two possible solutions now:

1. I don't use hasRole(..) but rather hasAuthority(...) and can rely on the default implementation NullAuthoritiesMapper
2. I keep on using hasRole(...), but instead of creating the SimpleAuthorityMapper in place I expose it as a @Bean and your framework picks it up automatically (one drawback: it needs to be registered outside the KeycloakSecurityConfiguration since otherwise it'd be a cyclic dependency)

This can be closed then as your library offers everything it should from my perspective.
Thanks for your amazing work and support!