Even when spring.security.user.name or spring.security.user.password has been configured, user details auto-configuration still backs off when resource server is on the classpath

[rozagerardo]

We've introduced the following feature with Boot 3.2:

https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.2-Release-Notes#auto-configured-user-details-service

Auto-configured User Details Service

The auto-configured InMemoryUserDetailsManager now backs off when one or more of spring-security-oauth2-client, spring-security-oauth2-resource-server, and spring-security-saml2-service-provider is on the classpath. Similarly, in reactive applications, the auto-configured MapReactiveUserDetailsService now backs off when one or more of spring-security-oauth2-client and spring-security-oauth2-resource-server is one the classpath.

If you are using one of the above dependencies yet still require an InMemoryUserDetailsManager or MapReactiveUserDetailsService in your application, define the required bean in your application.

Since spring-security-oauth2-authorization-server brings the spring-security-oauth2-resource-server as one of its dependencies, the default User Details Service backs off and the login authentication method fails with the minimal configuration suggested by the AS docs (here).

IMO it's expected and desirable (for a minimal configuration, of course) that a user can log in using the user/password authentication method to grant access to the OAuth2 Client to its resources.

So, I'd personally change the feature behavior to back off the default InMemoryUserDetailsManager for the conditions given above, and if the spring-security-oauth2-resource-server is not present in the dependencies.

Let me know what you think. This has also been reported as an Spring Authorization Server issue:

spring-projects/spring-authorization-server#1475

I guess before they can act upon this, it's on the Spring Boot's project to decide whether the default behavior should accommodate to the Spring AS minimal config (as I suggested above), or if it's ok as it is, and the Spring AS has to modify the minimal config guidelines, instructing to define a InMemoryUserDetailsManager bean in the context as well.

[wilkinsona]

So, I'd personally change the feature behavior to back off the default InMemoryUserDetailsManager for the conditions given above, and if the spring-security-oauth2-resource-server is not present in the dependencies.

We can't do that, I'm afraid. Avoiding the warning about the generated password when using resource server was one of the primary motivators for #35338.

We think we may be able to improve the situation here by changing the conditions so that the auto-configuration does not back off if you've set spring.security.user.name and/or spring.security.user.password. That won't restore things exactly as they were in 3.1, but I think it's a good compromise. Authorization Server's minimal setup will then work with the small addition of setting spring.security.user.password

[rozagerardo]

Thanks for the response @wilkinsona. Sounds like a suitable solution to me.

I have also been getting familiarized a little bit with the conditional mechanism for auto-configurations, and I think I understand why the logic I suggested wouldn't be achievable. (BTW, I now see I made an error in my suggestion, I meant "if the spring-security-oauth2-authorization-server is not present in the dependencies.", not the RS one of course, but I guess you got the point anyway😄).

Thanks for looking into this.

[seabamirum]

I'm using reactive Spring Security, and just upgraded to Spring Boot 3.4. I had to add exclude = UserDetailsServiceAutoConfiguration.class in order to get rid of this warning. Does @ConditionalOnMissingBean need to include the ReactiveAuthenticationManager ?

[wilkinsona]

It's impossible to say with certainty without knowing more. If you'd like us to investigate, please open a new issue with a minimal sample that reproduces the problem and we'll take a look.

[seabamirum]

For now I've just reverted to 3.3.6 and the warning goes away. It's strange though that UserDetailsServiceAutoConfiguration is getting invoked at all when @EnableWebFlux and @EnableWebFluxSecurity are used.