Spring Security Command-level Authorization Interceptors

[bankras]

Adding interceptors to enable spring-security for command level authorization.

To use these processors in your Axon based application:

1. register the AuthorizationMessageDispatchInterceptor as an dispatchInterceptor on your CommandGateway.
   This will make sure the principals username and grantedAuthorities are copied from the SecurityContext tot the command messages.
2. register the CommandAuthorizationInterceptor as an handlerInterceptor on your CommandBus. This will verify
   the authorities on the command, set by @PreAuthorize, with the users granted authorities.

[CLAassistant]

All committers have signed the CLA.

[smcvb]

Some remarks about copyright notices, some about JavaDoc, but also some about potential exceptions and making the introduced interceptors more generic.

In all, I think there's value in this PR, However, let's first discuss what's there before merging.

[smcvb]

I would like to hear your opinion for this interceptor concerning making it more generic by allowing any Message. So, a similar change request as I've placed on the AuthorizationMessageDispatchInterceptor.

If we would make that change, I do think we should rename this class to the MessageAuthorizationInterceptor.
Or, if we want to be extremely specific, the SpringSecurityAuthorizationInterceptor.

[bankras]

Like it, done it!
There might be need for a QueryInterceptorTest.

[smcvb]

Is there a chance any of this might throw a NullPointerException?

[bankras]

getContext() is guaranteed never null. getAuthentication() might return null if no authenticatio information is available

[smcvb]

I believe the Class#getAnnotation(Class) method returns null if the annotation isn't present.
Perhaps it's good to first check if the annotation is present at all.

You could benefit from the AnnotationUtils within Axon Framework and, for example, use the AnnotationUtils#isAnnotationPresent(AnnotatedElement, Class) operation.

If that returns true, then we can do the validation.
Otherwise, we got a choice to make:

1. Throw the unauthorized exception since somebody forgot to add the annotation.
2. Simply allow it, as we don't care.

I'm leaning more towards option 1, as somebody would consciously set this interceptor, I believe...
However, there just might be exceptions to the rule for some users.

[bankras]

I would lean towards 2. While the interceptor is put there on purpose, not all commands/queries require authorization. So the choice becomes:

2.1. Require PreAuthorize annotation on all messages, but without role or with generic role restriction
2.2. Do not require PreAuthorize annotation for messages that do not require authorization.

[abuijze]

Good to see you back here, @bankras

I was wondering if you had considered using a HandlerEnhancerDefinition instead of a MessageHandlerInterceptor? Or maybe there is a place fo both.
Using a HandlerEnhancerDefinition would allow one to annotate the @CommandHandler with @PreAuthorize instead of the payload of the message.

[bankras]

I wasn't aware of the option, but it's an interesting one. Surely beats url-pattern authorization.

Other paths I've been thinking about since Steven's remark:

• If we use query authorization, do we want support for post filtering?
• Do we need support to authorize based on aggregate state?
• Do we need support for an expression language?

[bankras]

This needs to be adjusted, because 'value' can be a SpEL