With the introduction of AuthorizationManager, it may be valuable to have an implementation that makes authorization decisions based on method annotations.
Comment From: evgeniycheban
@jzheaux I can take this.
Comment From: jzheaux
Thanks, @evgeniycheban!
It may be equally tricky to remain backward compatible with ConfigAttributes and metadata sources with this ticket as it was with the filter equivalent.
One way to address this could be to introduce a new annotation @EnableMethodSecurity which would eventually replace @EnableGlobalMethodSecurity. The new annotation would import a new MethodSecurityConfiguration class in charge of publishing the appropriate method interceptor. This would allow applications to opt-in in the same way authorizeHttpRequests does.
Comment From: evgeniycheban
@jzheaux I've created a draft PR with @Secured annotation method security implementation, could you please take a look?
I’m currently implementing the @PreAuthorize annotation support.
Comment From: rwinch
@evgeniycheban First, thank you for all your contributions as of late! You probably noticed this issue got re-opened. Unfortunately, at the last minute I noticed some things that needed to be changed which meant that we had to revert the changes for now.
Given that 5.5.0-RC1 (which means no more changes to the APIs can be made) is tonight and we won't have time for the changes this feature will be moved to 5.6-M1 which will take place in July.
Comment From: rwinch
The commits we should use to start are:
20778f727b873fd54bb64fd6ac5c9ed22dea9002 45376b359bfe5b4dc3fb36f0d7e500003d8835d5 68cf74468c57fe8719a4682e781f3f9171181edb 62d77ec97ea3335abd065138e6da76a3223f36d3 2b494ebc5f92ea157a8318f4bc863cc7d6eaac7d 6828987b4bd837e3bc78c16cb0c26df339cc3d5d 6bcf4796598221c91beb4ed910e2a48b88e42a2b 122346bd272b590d656bc7afefdc7c92e9a827f1 df8abcfae763bb87d2d3dfc6d4b9b57b68b209b5