There may be some value in introducing PermissionAuthorizationManager to allow a programmatic equivalent to hasPermission available through SpEL and SecurityExpressionRoot.
Comment From: evgeniycheban
@jzheaux I'd like to work on this.
Comment From: jzheaux
Thanks for putting together a PR, @evgeniycheban, so it was a little easier to consider what this would look like.
After reviewing it, I don't think PermissionAuthorizationManager provides enough value to add to Spring Security at this time.
Method security is still primarily reliant on SpEL, so there is little incentive there for a programmatic alternative. Further, if someone did want to use this class, they'd still certainly have to customize things since one needs to still extract the target (e.g. one of the method arguments) from the MethodInvocation.
Filter security also would have to customize things since one needs to extract the targetId (e.g. one of the path variables) from the RequestAuthorizationContext.
As such, I think we should wait until it's clearer in what circumstances an application could benefit from PermissionAuthorizationManager. I've made a note to add instructions in the migration guide for hasPermission, and we can evaluate the feedback there.
Otherwise, I'm going to close this ticket for now. We can always reopen should the manager's helpfulness become clearer.
Comment From: rwinch
Just chiming in here. PermissionEvaluator was nice because it allowed for simplified API for users to implement to customize authorization, but AuthorizationManager already provides a very simple API for this.