AuthorizationManager + Method Security Support

[evgeniycheban]

Closes gh-9289

[jzheaux]

Thanks, @evgeniycheban! This is a good start.

I've left some feedback inline. In addition to that, please keep classes final until there is a clear need for extension.

I have some additional thoughts, but I'm guessing they will shake out when you add Pre/PostAuthorize support.

[evgeniycheban]

@jzheaux I added support for Pre/PostAuthorize, please take a look. I'm currently covering the code with tests.

[jzheaux]

Thanks, @evgeniycheban! I've left some additional feedback.

[jzheaux]

Thanks, @evgeniycheban! I've left my feedback inline.

[jzheaux]

I like this interface, though I wonder if a better name is AuthorizationManagerAfterAdvice. The reason for that is that it's clear from the name that it is intercepting and perhaps mutating the return value.

[evgeniycheban]

Renamed to AuthorizationManagerAfterAdvice.

[jzheaux]

This looks great, @evgeniycheban! It's really starting to take shape. I've left some feedback inline.

[jzheaux]

I think you could instead do:

this.pointcut = Pointcuts.union(this.beforeAdvice, this.afterAdvice);

Then, you can remove the inner class.

[evgeniycheban]

Done.

[jzheaux]

I know Spring Security did a lot of this in the past, but I'd like to see if this can be changed to be bean-based instead of based on extending a class.

One way that might work would be to do:

@Autowired(required = false)
public void setMethodSecurityExpressionHandler(MethodSecurityExpressionHandler custom) {
    this.methodSecurityExpressionHandler = custom;
}

[jzheaux]

If successful, then let's also make the class final

[evgeniycheban]

The @Configuration class cannot be final because Spring creates a CGLIB proxy for it. I think we could make it just package private.

[evgeniycheban]

In fact, setting the proxyBeanMethods attribute to false allows the @Configuration class to be final.

[evgeniycheban]

Done

[jzheaux]

It might not go into this PR, but it would be nice if an application could do:

@Bean 
public AuthorizationManagerBeforeAdvice<MethodInvocation> myBeforeAdvice() {
    // ....
}

@Bean 
public AuthorizationManagerAfterAdvice<MethodInvocation> myAfterAdvice() {
    // ...
}

And MethodSecurityConfiguration would take that one instead of its own.

This would be the equivalent of supplying a custom SecurityMetadataSource

[evgeniycheban]

Done.

[jzheaux]

While the class is expression-based, it would be ambiguous if other expression-based ways to give advice were added later on to the framework. We might want to call this PreAnnotationAuthorizationManagerAfterAdvice.

[evgeniycheban]

Done.

[jzheaux]

I think this should match the AffirmativeBased matcher, since that's the default in @EnableGlobalMethodSecurity. It returns the first voter that grants and only denies if one of the voters denied.

[evgeniycheban]

Done. In the current version the DelegatingAuthorizationManagerBeforeAdvice returns the first granted AuthorizationDecision and the denied AuthorizationDecision only if one of the DelegatingAuthorizationManagerBeforeAdvices denied. If multiple DelegatingAuthorizationManagerBeforeAdvices denies then the first denied AuthorizationDecision is returned.

[jzheaux]

I'd recommend that this change to a setter. Typically, Spring Security places required parameters in the constructor and optional ones as setters. Since there's a default handler that will work in most cases, using the default constructor will make it more convenient for applications to use.

[evgeniycheban]

Done.

[evgeniycheban]

@jzheaux I've updated the PR according to your comments.

[jzheaux]

Thanks for your patience, @evgeniycheban, while I got back to you.

I've left some additional feedback inline.

[jzheaux]

@rwinch made a good point that it would be nice to see if we can change AuthorizationManagerBeforeAdvice so that it doesn't extend AuthorizationManager.

Two ideas come to mind:

1. Change this constructor to

public AuthorizationMethodInterceptor(AuthorizationManagerBeforeAdvice<MethodInvocation> beforeAdvice,
        AuthorizationManager<MethodInvocation> beforeManager,
        AuthorizationManagerAfterAdvice<MethodInvocation> afterAdvice,
        AuthorizationManager<MethodInvocation> afterManager)

and then PreAnnotationAuthorizationManagerBeforeAdvice would split into two classes --PreFilterAuthorizationManagerBeforeAdvice and PreAuthorizeAuthorizationManager -- and likewise for PostAnnotationXXX
2. Keep the contract as-is, but split PreAnnotationAuthorizationManagerBeforeAdvice into PreFilterAuthorizationManagerBeforeAdvice and something like MethodMatcherAuthorizationManagerBeforeAdvice. The latter would could have an instance of AuthorizationManager (e.g. PreAuthorizeAuthorizationManager) that it would delegate to if the MethodMatcher matches.

The second seems ideal, but I'm listing both for completeness.

In both cases, it seems like the before advice contract would change to return void since not all advices would return an AuthorizationDecision anymore.

[jzheaux]

Thanks for the updates, @evgeniycheban!

I've left some additional feedback inline.

Also, we're probably close enough to add @since 5.5 to new classes.

[jzheaux]

I think this class is no longer needed. DefaultPointcutAdvisor should suffice.

[evgeniycheban]

Done.

[jzheaux]

Let's please move all these classes to org.springframework.security.authorization.method.

[evgeniycheban]

Done.

[jzheaux]

I'm thinking it would be better to have this use MethodAuthorizationContext instead of MethodInvocation. That way, only one MethodAuthorizationContext needs to be generated in AuthorizationMethodInterceptor.

[evgeniycheban]

Done.

[evgeniycheban]

@jzheaux I updated the PR with the JSR-250 security annotations support.

[jzheaux]

Thanks again for all the hard work on this PR, @evgeniycheban, it's much appreciated! It's been merged in 20778f7. I also added some polish commits relative to documentation and some small bug fixes.

Finally, since we are close to release time, I polished the AOP structure, changing the advice classes to interceptors. These match very nicely with the surrounding interceptor and remove a number of classes needed to support the previous structure.