`authorizeHttpRequests` should pick up `AuthorizationManager` bean

[jzheaux]

authorizeHttpRequests replaces authorizeRequests. Specifically, it presents applications with the option to use a simplified API for programmatic authorization through AuthorizationManager.

It would be nice to pick up authorization manager @Beans and apply them by default. This would simplify constructs like:

@Bean 
SecurityFilterChain web(HttpSecurity http, AuthorizationManager<RequestAuthorizationContext> manager) throws Exception {
    http
        .authorizeRequests((authorize) -> authorize
            .anyRequest().access(manager)
        )
        // ...
}

@Bean 
AuthorizationManager<RequestAuthorizationContext> manager() {
    return AuthorityAuthorizationManager.hasRole("USER");
}

to become:

@Bean 
SecurityFilterChain web(HttpSecurity http) throws Exception {
    http
        .authorizeRequests(Customizer.withDefaults())
        // ...
}

@Bean 
AuthorizationManager<HttpServletRequest> manager() {
    return AuthorityAuthorizationManager.hasRole("USER");
}

Then, applications can specify the authorization subsystem simply by publishing a bean.

[jzheaux]

After having added this, I've had some second thoughts. While it is nice to reduce DSL boilerplate, that's not historically the primary motivation for accepting a @Bean. Generally when we add @Bean support to the DSL, it's because we anticipate reuse of that bean in other parts of the application or it's because we need that component to participate in the Framework's bean lifecycle.

The nice thing about the DSL is that you have all your security configurations in one discoverable location, having all the benefits of auto-complete and the associated documentation. So, I think what we'd want to do first is consider adding an authorizationManager method to authorizeHttpRequests.

In the context of a Boot application where several HttpSecurity defaults are already specified, a more effective way to reduce DSL boilerplate is likely to introduce some kind of HttpSecurityCustomizer so the entire HttpSecurity can be post-processed instead of just authorization.

That said, I'm open to the possibility that there are compelling cases out there that having picking up an AuthorizationManager @Bean really simplifies. This ticket can be revisited if such a use case surfaces.