GlobalMethodSecurity and multiple annotation ordering

[vguna]

Summary

Adding multiple security annotations to a method like this:

@RolesAllowed("ROLE_ADMIN")
@PostAuthorize("hasPermission(...)")
public SomeObject doSomething() {
}

leads to the effect, that @RolesAllowed doesn't seem to be checked anymore if @PostAuthorize returned true.

Actual Behavior

Since @PostAuthorize returns true, @RolesAllowed seems not evaluated anymore.
If I remove the @PostAuthorize access is denied as expected.

Is there something to change the actual behavior?

Expected Behavior

All annotations are processed and if at least one denies access, the complete access should be denied.

Configuration

See code snippet above.

Version

3.2.5-RELEASE

[KyleMoser]

Just a suggestions: you may be able to accomplish this by implementing your own AccessDecisionManager and/or AccessDecisionVoter(s). The AccessDecisionManager passes GrantedAuthority information to the Voter(s). It would be pretty simple to change the logic from the default "or" to "and" to make authorization decisions.

[vguna]

Yeah probably :). Just wanted to check, if this is the expected behavior and if so, if there's a builtin option to change that behavior.

[KyleMoser]

I am not a spring security developer but I have used this part of the framework extensively. I can tell you that yes, that is definitely the expected behavior. Also, implementing your own AccessDecisionManager and/or AccessDecisionVoter (whichever is easier) is the supported (builtin) way to modify the framework's behavior. If you look through the source code for the AccessDecisionManager class, in the decide method, the behavior is pretty easy to understand. Also, typically the chat at https://gitter.im/spring-projects/spring-security would be a much better place for the discussion (hope that doesn't come off as rude, just trying to help). See the sections on customizing the accessdecisionmanager at e.g. https://docs.spring.io/spring-security/site/docs/3.0.x/reference/ns-config.html

[jzheaux]

Closing in favor of #9630