Summary

The usual Spring MVC Security allows us to reference beans in the web security expressions:

http
        .authorizeRequests()
                .antMatchers("/user/**").access("@webSecurity.check(authentication,request)")
                ...

Currently the reactive version doesn't offer an access method with a String for web expressions, only with a ReaciveAuthorizationManager.

Actual Behavior

This is the API offered by pathMatchers

.authorizeExchange()
                    .pathMatchers("").access( ReaciveAuthorizationManager ... )

Expected Behavior

Possibility of configuring a security web expression:

http
        .authorizeExchange()
                .antMatchers("/user/**").access("@webSecurity.check(authentication,request)")
                ...

Configuration

...

Version

5.2.0.RC1

Comment From: jzheaux

Thanks for the suggestion, @codependent. How is the webSecurity bean in your sample materially different from publishing a ReactiveAuthorizationManager implementation and using that? It seems like the logic in webSecurity#check would be nearly identical to a concrete ReactiveAuthorizationManager implementation.

Generally speaking, I don't see the appeal to using SpEL when it's simple to provide a concrete, unit-testable authorization implementation instead. Additionally, applications have tended over the years to embed an unhealthy amount of logic in their security SpEL expressions, so I'm hesitant to add a feature that encourages that practice.

Comment From: codependent

@jzheaux as you say implementing ReactiveAuthorizationManager is nearly equivalent to what the SpEL expression would do. I was used to the Spring MVC approach and thought it would be nice to have in Webflux as well. In any case I see your point regarding the risk of arbitrary SpEL so feel free to discard the issue if you think it's better not to have this.

Thanks for considering it anyway.

Comment From: jzheaux

Let's see where #11105 goes -- it may be value to add the same to the reactive side.