2.7.6 -> 3.0.1 @EnableMethodSecurity Not Registered For @SpringBootTest with @AutoConfigureMockMvc

[adase11]

I'm migrating from v2.7.6 -> 3.0.1 and I had previously upgraded SpringSecurity to v5.8 in preparation for the full 3.x upgrade (as suggested in the Spring Boot 3.0 Migration Guide ). For v5.8 I had opted into the v6 defaults as outlined in the 5.8 guide and transitioned from using @EnableGlobalMethodSecurity to @EnableMethodSecurity.

I have tests that use the following setup:

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT, classes = {MyApplication.class, CustomMockMvcConfiguration.class})
@AutoConfigureMockMvc

My tests use a custom implementation of @WithSecurityContext to set up the security context.

I use @PreAuthorize for method security in my application and enable @PreAuthorize annotations with @EnableMethodSecurity. My class annotated with @EnableMethodSecurity looked like this:

@EnableMethodSecurity
public class MethodSecurityConfig {

}

After upgrading to Spring Boot v3.0.1 I found that my tests started to fail when the test expected a forbidden response. The request should have been failing a @PreAuthorize condition but was not.

After some investigation I was able to determine that my @PreAuthorize logic was no longer being executed for the failing tests. This looks to be because @EnableMethodSecurity dropped the meta annotation @Configuration between version 5.8 & 6.x. I am ok with fixing this by also annotating my MethodSecurityConfig class with @Configuration however I think that it could be useful for WebMvcTypeExcludeFilter to include org.springframework.security.config.annotation classes or at least mention this change in the migration guide.

[wilkinsona]

I think that it could be useful for WebMvcTypeExcludeFilter to include org.springframework.security.config.annotation classes

I don't think that this would help. The filter only applies to beans that are found via component scanning. Without @Configuration on @EnableMethodSecurity, it won't be annotated with @Component so it won't be found by scanning irrespective of what the filter does.

or at least mention this change in the migration guide

I think it would be worth mentioning this change in Spring Security 6.0's migration guide. Can you please open a Spring Security issue?

[adase11]

Thanks @wilkinsona - I'll open something with Spring Security. Appreciate you taking a look