Client roles mock about spring-addons

[ch4mpy]

Short answer: @WithMockKeycloakAuth({"ADMINISTRATOR", "DRIVER"}) just above your @Test as demonstrated in samples and on stackoverflow answers.

Long answer: authorities (in Spring-security world a role is an authority prefixed with ROLE_) are populated from a JWT by an authorities converter. Keycloak get authorities from different claims to retrieve realm roles and client roles. You need to explore Keycloak sources (starting from KeycloakWebSecurityConfigurerAdapter) if you are interested in figuring out how this is exactly done.

In your sample, you are setting roles in a claim named resource_access.ace-ella-ecosystem.roles (yes, a claim name is a JSON string and yes, JSON string can contain dots) when keycloak expects a roles string-array claim inside a ace-ella-ecosystem claim-set itself inside a resource_access claim-set. As this is pretty cumbersome to declare with @ClaimSet and @StringArrayClaim (not @StringClaim as you did), I recently created a @JsonObjectClaim that works close to what you wrote. But the simple sollution to set authorities is clearly to use authorities property on @WithMockKeycloakAuth.

[cvetan]

@ch4mpy I still get 403 even with your example.

The test:

@Test
    @WithMockKeycloakAuth({"ADMINISTRATOR", "DRIVER"})
    void exampleTest() throws Exception {
        var uri = URI.create("/v1/support");

        mockMvc.perform(
                        MockMvcRequestBuilders.post(uri)
                )
                .andExpect(MockMvcResultMatchers.status().isOk());

    }

However since we are using client roles, we have this in configuration:

keycloak:
  auth-server-url: ${KEYCLOAK_AUTH_SERVER_URL}
  realm: ${KEYCLOAK_REALM}
  resource: ${KEYCLOAK_RESOURCE}
  public-client: true
  ssl-required: external
  bearer-only: true
  use-resource-role-mappings: true

[ch4mpy]

Had missed

simpleAuthorityMapper.setPrefix("ROLE_");

Have you tried @WithMockKeycloakAuth({"ROLE_ADMINISTRATOR", "ROLE_DRIVER"}) ?

[cvetan]

Thanks, that works. I haven't though about it, because token has roles without prefix. I can't believe solution was this simple. 😄

Anyways everything works, thank you very much, you helped a lot. 🍺

[cvetan]

Hi, @ch4mpy me again :D

I have slightly more complicated use case now, I need to check role inside some service class and I do that like this:

var allowedRoles = getAllowedRoles().stream()
                .map(UserRole::toString)
                .collect(Collectors.toSet());
        var userRoles = accessToken
                .getResourceAccess(keycloakResource)
                .getRoles();

However when this code runs inside test, I get following exception:

             Body = {"error_code":null,"error_description":null,"exception_class":"java.lang.NullPointerException","exception_message":"Cannot invoke \"org.keycloak.representations.AccessToken$Access.getRoles()\" because the return value of \"org.keycloak.representations.AccessToken.getResourceAccess(String)\" is null"}

I tried following your advice from first message to this question (about nesting claims resource_access -> resource_id -> roles), however I can't seem to understand that approach nor how to nest them. You mentioned something about json object claim, so maybe that is the right way, but if you could tell me something more or just point me in right direction I would apreciate it.

Thanks

[ch4mpy]

If you want a RessourceAccess to be be populated in your tests, you just need to populate it with something like:

@WithMockKeycloakAuth(accessToken = @KeycloakAccessToken(resourceAccess = @KeycloakResourceAccess(resourceId = "demo", access = @KeycloakAccess(roles = {"machin", "truc"}))))

Setting authorities with @WithMockKeycloakAuth can't populate claims. Keycloak-spring adapter retrieves authorities from several places: at least "client roles" (by default resource_access.{clientId}.roles) and "realm roles" (by default realm_access.roles).

I write "by default", because this is configurable with mappers and can actually be set to about anything.

I have a strong recomandation for you: use direct claim access for stuff that are neither authorities nor standard OpenID claims (subject, preferredUserName, etc.).
The mapping from claims to authorities should be made in spring security conf.
Access to authorities in your application code should be done exclusively with KeycloakAuthenticationToken::getAuthorities.

=> Read Keycloak doc to figure out how to map your Keycloak "roles" claims to Spring "authorities" and then use:

• keycloakAuthenticationToken.getAuthorities() in your application code (that's what do implicitely @PreAuthorise(hasAnyAuthority(...)) and @PreAuthorise(hasAnyRole(...)))
• @WithMockKeycloakAuth(authorities= {...}) in your tests