Add support for authorization events in DelegatingAuthorizationManager

[parikshitdutta]

• added AuthorizationSuccessEvent to represent event for granted AuthorizationDecision

• added AuthorizationFailureEvent to represent event for denied AuthorizationDecision

• added AuthorizationEventPublisher to represent generic publisher for raising authorization events

• added default implementation [DefaultAuthorizationEventPublisher] for AuthorizationEventPublisher

• added DefaultAuthorizationEventPublisherTests to handle respective test scenarios

• updated DelegatingAuthorizationManager to add AuthorizationEventPublisher to raise authorization events

• updated DelegatingAuthorizationManagerTests to add respective test scenarios

Closes #9288 and #9286

[parikshitdutta]

@jzheaux one thing I am possibly missing out is configuring the DefaultAuthorizationEventPublisher, which I believe could be part of DelegatingAuthorizationManager.Builder and/or AuthorizeHttpRequestsConfigurer.

Please help me understand that as well, as you share your feedback on other things.

[jzheaux]

Thanks, @parikshitdutta! Sorry that it took some time to get back to this.

In addition to publishing an event in AuthorizationFilter, I think the same events should be published in AuthorizationManagerBeforeMethodInterceptor and AuthorizationManagerAfterMethodInteceptor. Would you be able to add that as well including tests?

[jzheaux]

I think this interface should be left out for now. Instead, I think that classes can use ApplicationEventPublisher.

[jzheaux]

I think this should be generically typed like AuthorizationManager is. Also, I think it should be modeled after the former AuthorizationFailureEvent with some changes:

public class AuthorizationFailureEvent<T> extends ApplicationEvent {
    // ...

    public AuthorizationFailureEvent(Supplier<Authentication> authentication, T object, AuthorizationDecision decision)

    // ...
}

My motivation for the ordering is that it matches the ordering for AuthorizationManager#check.

[jzheaux]

I think this should be generically typed like AuthorizationManager is. Also, I think it should be modeled after the former AuthorizedEvent with some changes:

public class AuthorizationSuccessEvent<T> extends ApplicationEvent {
    // ...

    public AuthorizationSuccessEvent(Supplier<Authentication> authentication, T object, AuthorizationDecision decision)

    // ...
}

My motivation for the ordering is that it matches the ordering for AuthorizationManager#check.

[jzheaux]

Since authorization managers can be reasonably composed, I think it would be better to publish the event in AuthorizationFilter instead. This would also mean changing AuthorizationFilter to call AuthorizationManager#check instead of #verify.

This way, if a custom authorization manager or a composite authorization manager is used, we don't risk multiple events or no events firing.

[eleftherias]

Hi @parikshitdutta, have you had the chance to look at the feedback?

[jzheaux]

@parikshitdutta, thanks for your contribution!

This is now merged into 5.7.x and main. I also added some polish commits that add documentation, configuration support, and update the contracts according to the feedback specified in my original review.