1. Overview
We’ve created the UserDetailsConfig configuration class that produces an InMemoryUserDetailsManager bean. Inside the factory method, we’ve used a PasswordEncoder required for user details passwords.
Next, we’ll add the endpoint we want to call:
@RestController
public class TestSecuredController {
@GetMapping("/test-resource")
public ResponseEntity<String> testAdmin() {
return ResponseEntity.ok("GET request successful");
}
}
We’ve added a simple GET endpoint that should return a 200 status code.
Let’s create a security configuration:
@Configuration
@EnableWebSecurity
public class DefaultSecurityJavaConfig {
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
return http.authorizeHttpRequests (authorizeRequests -> authorizeRequests
.requestMatchers("/test-resource").hasRole("ADMIN"))
.httpBasic(withDefaults())
.build();
}
}
Here we’ve created a SecurityFilterChain bean where we specified that only the users with ADMIN role can access the test-resource endpoint.
Now, let’s add these configurations to our test context and call our secured endpoint:
@WebMvcTest(controllers = TestSecuredController.class)
@ContextConfiguration(classes = { DefaultSecurityJavaConfig.class, UserDetailsConfig.class,
TestSecuredController.class })
public class DefaultSecurityFilterChainIntegrationTest {
@Autowired
private WebApplicationContext wac;
private MockMvc mockMvc;
@BeforeEach
void setup() {
mockMvc = MockMvcBuilders
.webAppContextSetup(wac)
.apply(SecurityMockMvcConfigurers.springSecurity())
.build();
}
@Test
void givenDefaultSecurityFilterChainConfig_whenCallTheResourceWithAdminRole_thenForbiddenResponseCodeExpected() throws Exception {
MockHttpServletRequestBuilder with = MockMvcRequestBuilders.get("/test-resource")
header("Authorization", basicAuthHeader("admin", "password"));
ResultActions performed = mockMvc.perform(with);
MvcResult mvcResult = performed.andReturn();
assertEquals(403, mvcResult.getResponse().getStatus());
}
}
We’ve attached the user details configuration, security configuration, and the controller bean to our test context. Then, we called the test resource using admin user credentials, sending them in the Basic Authorization header. But instead of the 200 response code, we face the Forbidden response code 403.
If we deep dive into how the AuthorityAuthorizationManager.hasRole() method works, we’ll see the following code:
public static <T> AuthorityAuthorizationManager<T> hasRole(String role) {
Assert.notNull(role, "role cannot be null");
Assert.isTrue(!role.startsWith(ROLE_PREFIX), () -> role + " should not start with " + ROLE_PREFIX + " since "
+ ROLE_PREFIX + " is automatically prepended when using hasRole. Consider using hasAuthority instead.");
return hasAuthority(ROLE_PREFIX + role);
}
As we can see – the ROLE_PREFIX is hardcoded here and all the roles should contain it to pass a verification. We face a similar behavior when using method security annotations such as @RolesAllowed.
3. Use Authorities Instead of Roles
The simplest way to solve this issue is to use authorities instead of roles. Authorities don’t require the expected prefixes. If we’re comfortable using them, choosing authorities helps us avoid problems related to prefixes.
3.1. SecurityFilterChain-Based Configuration
Let’s modify our user details in the UserDetailsConfig class:
@Configuration
public class UserDetailsConfig {
@Bean
public InMemoryUserDetailsManager userDetailsService() {
PasswordEncoder encoder = PasswordEncoderFactories.createDelegatingPasswordEncoder();
UserDetails admin = User.withUsername("admin")
.password(encoder.encode("password"))
.authorities(Arrays.asList(new SimpleGrantedAuthority("ADMIN"),
new SimpleGrantedAuthority("ADMINISTRATION")))
.build();
return new InMemoryUserDetailsManager(admin);
}
}
We’ve added an authority called ADMINISTRATION for our admin user. Now we’ll create the security config based on authority access:
@Configuration
@EnableWebSecurity
public class AuthorityBasedSecurityJavaConfig {
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
return http.authorizeHttpRequests (authorizeRequests -> authorizeRequests
.requestMatchers("/test-resource").hasAuthority("ADMINISTRATION"))
.httpBasic(withDefaults())
.build();
}
}
In this configuration, we’ve implemented the same access restriction concept but used the AuthorityAuthorizationManager.hasAuthority() method. Let’s set the new security configuration into a context and call our secured endpoint:
@WebMvcTest(controllers = TestSecuredController.class)
@ContextConfiguration(classes = { AuthorityBasedSecurityJavaConfig.class, UserDetailsConfig.class,
TestSecuredController.class })
public class AuthorityBasedSecurityFilterChainIntegrationTest {
@Autowired
private WebApplicationContext wac;
private MockMvc mockMvc;
@BeforeEach
void setup() {
mockMvc = MockMvcBuilders
.webAppContextSetup(wac)
.apply(SecurityMockMvcConfigurers.springSecurity())
.build();
}
@Test
void givenAuthorityBasedSecurityJavaConfig_whenCallTheResourceWithAdminAuthority_thenOkResponseCodeExpected() throws Exception {
MockHttpServletRequestBuilder with = MockMvcRequestBuilders.get("/test-resource")
.header("Authorization", basicAuthHeader("admin", "password"));
ResultActions performed = mockMvc.perform(with);
MvcResult mvcResult = performed.andReturn();
assertEquals(200, mvcResult.getResponse().getStatus());
}
}
As we can see, we could access the test resource using the same user with the authorities-based security configuration.
3.2. Annotation-Based Configuration
To start using the annotation-based approach we first need to enable method security. Let’s create a security configuration with the @EnableMethodSecurity annotation:
@Configuration
@EnableWebSecurity
@EnableMethodSecurity(jsr250Enabled = true)
public class MethodSecurityJavaConfig {
}
Now, let’s add one more endpoint to our secured controller:
@RestController
public class TestSecuredController {
@PreAuthorize("hasAuthority('ADMINISTRATION')")
@GetMapping("/test-resource-method-security-with-authorities-resource")
public ResponseEntity<String> testAdminAuthority() {
return ResponseEntity.ok("GET request successful");
}
}
Here, we’ve used the @PreAuthorize annotation with a hasAuthority attribute, specifying our expected authority. After the preparation is ready, we can call our secured endpoint:
@WebMvcTest(controllers = TestSecuredController.class)
@ContextConfiguration(classes = { MethodSecurityJavaConfig.class, UserDetailsConfig.class,
TestSecuredController.class })
public class AuthorityBasedMethodSecurityIntegrationTest {
@Autowired
private WebApplicationContext wac;
private MockMvc mockMvc;
@BeforeEach
void setup() {
mockMvc = MockMvcBuilders
.webAppContextSetup(wac)
.apply(SecurityMockMvcConfigurers.springSecurity())
.build();
}
@Test
void givenMethodSecurityJavaConfig_whenCallTheResourceWithAdminAuthority_thenOkResponseCodeExpected() throws Exception {
MockHttpServletRequestBuilder with = MockMvcRequestBuilders
.get("/test-resource-method-security-with-authorities-resource")
.header("Authorization", basicAuthHeader("admin", "password"));
ResultActions performed = mockMvc.perform(with);
MvcResult mvcResult = performed.andReturn();
assertEquals(200, mvcResult.getResponse().getStatus());
}
}
We’ve attached the MethodSecurityJavaConfig and the same UserDetailsConfig to the test context. Then, we called the test-resource-method-security-with-authorities-resource endpoint and successfully accessed it.
4. Custom Authorization Manager for SecurityFilterChain
If we need to use roles without the ROLE_ prefix, we must attach a custom AuthorizationManager to the SecurityFilterChain configuration. This custom manager won’t have hardcoded prefixes.
Let’s create such an implementation:
public class CustomAuthorizationManager implements AuthorizationManager<RequestAuthorizationContext> {
private final Set<String> roles = new HashSet<>();
public CustomAuthorizationManager withRole(String role) {
roles.add(role);
return this;
}
@Override
public AuthorizationDecision check(Supplier<Authentication> authentication,
RequestAuthorizationContext object) {
for (GrantedAuthority grantedRole : authentication.get().getAuthorities()) {
if (roles.contains(grantedRole.getAuthority())) {
return new AuthorizationDecision(true);
}
}
return new AuthorizationDecision(false);
}
}
We’ve implemented the AuthorizationManager interface. In our implementation, we can specify multiple roles that allow the call to pass the authority verification. In the check() method, we’re verifying if the authority from the authentication is in the set of our expected roles.
Now, let’s attach our customer authorization manager to SecurityFilterChain:
@Configuration
@EnableWebSecurity
public class CustomAuthorizationManagerSecurityJavaConfig {
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http
.authorizeHttpRequests (authorizeRequests -> {
hasRole(authorizeRequests.requestMatchers("/test-resource"), "ADMIN");
})
.httpBasic(withDefaults());
return http.build();
}
private void hasRole(AuthorizeHttpRequestsConfigurer.AuthorizedUrl authorizedUrl, String role) {
authorizedUrl.access(new CustomAuthorizationManager().withRole(role));
}
}
Instead of AuthorityAuthorizationManager.hasRole() method, here we’ve used AuthorizeHttpRequestsConfigurer.access() which allows us to use our custom AuthorizationManager implementation.
Now let’s configure the test context and call the secured endpoint:
@WebMvcTest(controllers = TestSecuredController.class)
@ContextConfiguration(classes = { CustomAuthorizationManagerSecurityJavaConfig.class,
TestSecuredController.class, UserDetailsConfig.class })
public class RemovingRolePrefixIntegrationTest {
@Autowired
WebApplicationContext wac;
private MockMvc mockMvc;
@BeforeEach
void setup() {
mockMvc = MockMvcBuilders
.webAppContextSetup(wac)
.apply(SecurityMockMvcConfigurers.springSecurity())
.build();
}
@Test
public void givenCustomAuthorizationManagerSecurityJavaConfig_whenCallTheResourceWithAdminRole_thenOkResponseCodeExpected() throws Exception {
MockHttpServletRequestBuilder with = MockMvcRequestBuilders.get("/test-resource")
.header("Authorization", basicAuthHeader("admin", "password"));
ResultActions performed = mockMvc.perform(with);
MvcResult mvcResult = performed.andReturn();
assertEquals(200, mvcResult.getResponse().getStatus());
}
}
We’ve attached our CustomAuthorizationManagerSecurityJavaConfig and called the test-resource endpoint. As expected, we received the 200 response code.
5. Override GrantedAuthorityDefaults for Method Security
In the annotation-based approach, we can override the prefix we’ll use with our roles.
Let’s modify our MethodSecurityJavaConfig:
@Configuration
@EnableWebSecurity
@EnableMethodSecurity(jsr250Enabled = true)
public class MethodSecurityJavaConfig {
@Bean
GrantedAuthorityDefaults grantedAuthorityDefaults() {
return new GrantedAuthorityDefaults("");
}
}
We’ve added the GrantedAuthorityDefaults bean and passed an empty string as the constructor parameter. This empty string will be used as the default role prefix.
For this test case we’ll create a new secured endpoint:
@RestController
public class TestSecuredController {
@RolesAllowed({"ADMIN"})
@GetMapping("/test-resource-method-security-resource")
public ResponseEntity<String> testAdminRole() {
return ResponseEntity.ok("GET request successful");
}
}
We’ve added the @RolesAllowed({“ADMIN”}) to this endpoint so only the users with the ADMIN role should be able to access it.
Let’s call it and see what the response will be:
@WebMvcTest(controllers = TestSecuredController.class)
@ContextConfiguration(classes = { MethodSecurityJavaConfig.class, UserDetailsConfig.class,
TestSecuredController.class })
public class RemovingRolePrefixMethodSecurityIntegrationTest {
@Autowired
WebApplicationContext wac;
private MockMvc mockMvc;
@BeforeEach
void setup() {
mockMvc = MockMvcBuilders
.webAppContextSetup(wac)
.apply(SecurityMockMvcConfigurers.springSecurity())
.build();
}
@Test
public void givenMethodSecurityJavaConfig_whenCallTheResourceWithAdminRole_thenOkResponseCodeExpected() throws Exception {
MockHttpServletRequestBuilder with = MockMvcRequestBuilders.get("/test-resource-method-security-resource")
.header("Authorization", basicAuthHeader("admin", "password"));
ResultActions performed = mockMvc.perform(with);
MvcResult mvcResult = performed.andReturn();
assertEquals(200, mvcResult.getResponse().getStatus());
}
}
We’ve successfully retrieved the 200 response code calling the test-resource-method-security-resource for the user having the ADMIN role without any prefixes.
6. Conclusion
In this article, we’ve explored various approaches to avoid issues with ROLE_ prefixes in Spring Security. Some methods require customization, while others use the default functionality. The approaches described in the article can help us avoid adding prefixes to the roles in our user details, which may sometimes be impossible.
As usual, the full source code can be found over on GitHub.