Add AuthorizationManager

[evgeniycheban]

Closes gh-8900

[jzheaux]

Thanks, @evgeniycheban, this is going in the right direction. I've left a couple of comments inline.

[jzheaux]

Great progress, @evgeniycheban, it's nice to see this starting to take shape. I've left some additional feedback inline.

[jzheaux]

Let's remove this reference once it's not used anymore.

[evgeniycheban]

It might make sense to consider introducing a new filter that will use an AuthorizationManager similar to AuthorizationWebFilter.

[jzheaux]

Agreed that it's worth considering. It doesn't change the fact that AbstractSecurityInterceptor needs to stop using AccessDecisionManager, but it would probably be worth it to file a ticket and start that conversation.

[jzheaux]

I think the ideal would be to initialize instances of AuthorizationManager with the correct security metadata instead of retrieving the security metadata each time an authentication is being checked.

Instead of routing the rules configured in the DSL through the ConfigAttribute API, have you already considered having the DSL construct a delegating AuthorizationManager that is composed of delegates that already have the security metadata?

[evgeniycheban]

I think this implementation requires less changes and we can reuse voters.
I'm not sure how this can be implemented for Method Security, the AffirmativeBasedAuthorizationManager is also used in GlobalMethodSecurityConfiguration.

[jzheaux]

While I agree that this might be less change, we don't want to introduce a public API that continues to have the same level of complexity as the existing API. The primary goal of this PR is to simplify the authorization API. Generally speaking, we ought to, going forward, avoid using the ConfigAttribute approach.

As you mentioned, this is more deeply embedded in method security. I wonder if this class could be package-private to method security configuration, and we can introduce another ticket to continue to rework method security.

[evgeniycheban]

I forget that AffirmativeBasedAuthorizationManager is also used for Web Socket configuration in AbstractSecurityWebSocketMessageBrokerConfigurer, maybe for now we can use an adapter for AccessDecisionManager and rework Method Security and Web Socket configurations in another ticket?

[jzheaux]

Thanks, @evgeniycheban! Let's now have @rwinch take a look as I anticipate that he will also have some feedback.

[rwinch]

Thanks for the PR @evgeniycheban! I'm really happy how this turned out.

I think we should revisit #8996 (comment)

If it is a bug, then I think we should create a separate ticket and commit with tests for it. This makes it easier for users to track changes (that it changed and why it changed). It also makes it easier for us to backport bug fixes.

[rwinch]

Suggested change

	/**
	* Determines if access should be granted for a specific authentication and object.
	* @param authentication the {@link Supplier} of the {@link Authentication} to check
	* @param object the {@link T} object to check
	* @return true if access is granted, false if denied
	*/
	default boolean isGranted(Supplier<Authentication> authentication, T object) {
	AuthorizationDecision decision = check(authentication, object);
	return decision == null || decision.isGranted();
	}

I'd prefer to leave this out to keep the interface as simple as possible and provide better symmetry to ReactiveAuthorizationManager. We can always add it later if necessary since it would be passive.

[evgeniycheban]

This is an old diff, please see the last (62283faa) commit.

[rwinch]

I think it might be better to make the constructor package scope and add some static factory methods like AuthorityReactiveAuthorizationManager does.

[evgeniycheban]

This is an old diff, please see the last (62283fa) commit.

[evgeniycheban]

@rwinch I reverted changes for MvcRequestMatcher and AntPathRequestMatcher.

[evgeniycheban]

@rwinch Currently, MvcRequestMatcher.matcher doesn't check HttpMethod and servletPath like MvcRequestMatcher.matches does. Should I create a separate ticket for this or leave my changes in this PR?

[jzheaux]

@evgeniycheban If the changes aren't required for this PR, then it's best to file a separate ticket, especially since the changes aren't related to the ticket that this PR is resolving.

The reason for that is it simplifies backporting bug fixes to other branches. Also, it makes release notes clearer for users that are affected by the bugs as they'll see a separate line item in the notes.

[jzheaux]

@evgeniycheban, I added #9284 and #9285 to address MvcRequestMatcher and AntPathRequestMatcher, respectively.

[jzheaux]

Thanks for all your work on this PR, @evgeniycheban! It's very exciting.

In addition to the above two tasks, I've created #9286, #9287, and #9288 for other improvements that we identified during the PR.