Spring Security authorizeExchange should pick up ReactiveAuthorizationManager bean

It would be nice to pick up a ReactiveAuthorizationManager @Bean and apply it by default to authorizeExchange.

This would simplify constructs like:

@Bean 
SecurityWebFilterChain web(ServerHttpSecurity http, ReactiveAuthorizationManager<AuthorizationContext> manager) {
    http
        .authorizeExchange((authorize) -> authorize
            .anyExchange().access(manager)
        )
        // ...
}

@Bean 
ReactiveAuthorizationManager<AuthrorizationContext> manager() {
    return AuthorityReactiveAuthorizationManager.hasRole("USER");
}

to become:

@Bean 
SecurityWebFilterChain web(ServerHttpSecurity http) {
    http
        .authorizeExchange(Customizer.withDefaults())
        // ...
}

@Bean 
ReactiveAuthorizationManager<ServerWebExchange> manager() {
    return AuthorityReactiveAuthorizationManager.hasRole("USER");
}

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

Comment From: 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 authorizeExchange.

In the context of a Boot application where several ServerHttpSecurity defaults are already specified, a more effective way to reduce DSL boilerplate is likely to introduce some kind of ServerHttpSecurityCustomizer so the entire ServerHttpSecurity 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 ReactiveAuthorizationManager @Bean really simplifies. This ticket can be revisited if such a use case surfaces.