WebFlux and resource server auto-configuration may fail due to null authentication manager

[tgeens]

Running into issues with upgrading 3.1.6 project to 3.2.0, using webflux + oauth2-resource-server:

Caused by: java.lang.IllegalArgumentException: authenticationManager cannot be null
	at org.springframework.util.Assert.notNull(Assert.java:172)
	at org.springframework.security.web.server.authentication.AuthenticationWebFilter.<init>(AuthenticationWebFilter.java:94)
...

Looks very similar to #37504

To reproduce:

• webflux + oauth-resource-server starters - Initializr link
• run contextLoads() test

Looks like in 3.2 the ReactiveUserDetailsServiceAutoConfiguration backs off because of the @ConditionalOnMissingClass ReactiveOpaqueTokenIntrospector that oauth-resource-server brings along.
In my @SpringBootTests I don't have any resource server configured, I'm expecting it to fall back to the default WebFluxSecurityConfiguration, as it did in 3.1.6

Looking at this, there would be another problem when you have oauth2-login on the classpath, which brings along ClientRepository ?

[wilkinsona]

Thanks for the report. It looks like the resource server-related auto-configurations are enabling web security in situations where they won't actually provide everything that's needed for that to succeed. We need to adjust the conditions on their WebSecurityConfiguration classes.

[tgeens]

@wilkinsona I'm very surprised with this change, Spring Boot 3.2.1-SNAPSHOT suddenly backs off applying any security ?

Even if oauth2-resource server is not "properly configured", I still expect everything to fall back to the ReactiveUserDetailsServiceAutoConfiguration ?

Given the following test:

@Test
void testUnauthorized(ApplicationContext context) {
	var client = WebTestClient.bindToApplicationContext(context).build();
	client.get().uri("/").exchange().expectStatus().isUnauthorized();
}

• Spring Boot 3.1.6: OK - HTTP 401
• Spring Boot 3.2.0: FAIL - context fails to load
• Spring Boot 3.2.1-SNAPSHOT: FAIL - HTTP 404

[wilkinsona]

That's not this change, it's #35338 that is causing that to happen. It failed with 3.2.0 as it wasn't backing off correctly and things were being left in a partial, broken state.

If resource server is on the classpath but you're not actually using it in certain situations then, as described in the release notes, you should define your own user details service in those situations.

[tgeens]

Thanks for the quick reply.

I realize #35338 is the original cause, but I'm not sure I understand. Should I open a new issue or do you consider this expected behaviour ?

[wilkinsona]

It's the expected behavior in order to avoid the unwanted warning described in #35338 that's triggered when the in-memory user details service is configured.

[wilkinsona]

As described in #38753, we need to find a better way to fix this.