Have you ever looked for a simple and flexible way to mock a security hierarchy and try it out in your rest controllers in Spring? After reading the Spring Security Reference I realized there are straightforward ways using AOP, which solutions often are the greatest ones for testing. For mocking credentials in Spring you can use the annotations @WithMockUser, @WithUserDetails and @WithSecurityContext, included in the artifact:
In most cases, @WithUserDetails gathers the flexibility and power I need.
How @WithUserDetails works?
Basically you just need to create a custom UserDetailsService with all the possible users profiles you want to test. E.g
Now we have our users ready, so imagine we want to test the access control to this controller function:
Here we have a get mapped function to the route /foo/salute and we are testing a role based security with the @Secured annotation, although you can test @PreAuthorize and @PostAuthorize as well.
Let’s create two tests, one to check if a valid user can see this salute response and the other to check if it’s actually forbidden.
As you see we imported SpringSecurityWebAuxTestConfig to provide our users for testing. Each one used on its corresponding test case just by using a straightforward annotation, reducing code and complexity.
Better use @WithMockUser for simpler Role Based Security
As you see @WithUserDetails has all the flexibility you need for most of your applications. It allows you to use custom users with any GrantedAuthority, like roles or permissions. But if you are just working with roles, testing can be even easier and you could avoid constructing a custom UserDetailsService. In such cases, specify a simple combination of user, password and roles with @WithMockUser.
Notice that now instead of the user firstname.lastname@example.org we are getting the default provided by @WithMockUser: user; yet it won’t matter because what we really care about is his role: ROLE_MANAGER.
As you see with annotations like @WithUserDetails and @WithMockUser we can switch between different authenticated users scenarios without building classes alienated from our architecture just for making simple tests. Its also recommended you to see how @WithSecurityContext works for even more flexibility.