Spring Security Resource server using AuthenticationManagerResolver and disabled anonymous authentication: "An AuthenticationManager is required"

Describe the bug When OAuth 2.0 Resource Server support is configured, in combination with disabling anonymous authentication, then org.springframework.security.access.intercept.AbstractSecurityInterceptor throws IllegalArgumentException with the message "An AuthenticationManager is required".

Similar to #8031, but my configuration has oauth2ResourceServer().authenticationManagerResolver(...) instead of oauth2ResourceServer().jwt().

To Reproduce Configure HttpSecurity similar to below and run the application.

http
    .authorizeRequests()
        .anyRequest().authenticated()
        .and()
    .anonymous().disable()
    .oauth2ResourceServer()
        .authenticationManagerResolver(new JwtIssuerAuthenticationManagerResolver("https://example.com"));

Expected behavior The application should start without requiring an AuthenticationManager to be configured.

Sample See https://github.com/cselagea/spring-security/commit/25931e59ce4d3409048714ae3388e4392068a054.

Comment From: jzheaux

Thanks for the report, @cselagea. This appears to be happening because AbstractSecurityInterceptor is expecting an AuthenticationManager.

It may be reasonable to relax that constraint -- I'll take a look.

In the meantime, please consider upgrading to authorizeHttpRequests which uses the new AuthorizationFilter. This new filter replaces AbstractSecurityInterceptor, like so:

http
    .authorizeHttpRequests()
        .anyRequest().authenticated()
        .and()
    .anonymous().disable()
    .oauth2ResourceServer()
        .authenticationManagerResolver(new JwtIssuerAuthenticationManagerResolver("https://example.com"));

Comment From: cselagea

Thanks for the tip, @jzheaux. Using authorizeHttpRequests works like a charm. I had seen this method, but frankly didn't know the difference. I was following the Spring Security documentation, which is how I ended up using authorizeRequests in the first place.

Comment From: jzheaux

@cselagea, I resolved to update the samples and the docs in lieu of relaxing the restriction in AbstractSecurityInterceptor, so I'll close the issue at this point. Apps should use authorizeHttpRequests these days.