DefaultMethodSecurityExpressionHandler createSecurityExpressionRoot Should Have Protected Access Instead Of Private

[adase11]

Describe the bug
DefaultMethodSecurityExpressionHandler for v5.8.0 adds a new signature for createSecurityExpressionRoot as createSecurityExpressionRoot(Supplier<Authentication> authentication, MethodInvocation invocation) in addition to the existing
createSecurityExpressionRoot(Authentication authentication, MethodInvocation invocation) . However, the new signature is private while the existing one is protected. This causes an issue for any usage that extends the DefaultMethodSecurityExpressionHandler and overrides the protected createSecurityExpressionRoot because the createEvaluationContext method always calls the private createSecurityExpressionRoot, leaving any extension of DefaultMethodSecurityExpressionHandler unable to override this behavior. A work around could be to also override createEvaluationContext however that method uses MethodSecurityEvaluationContext which is package private and therefore cannot be used when overriding createEvaluationContext.

Proposed Fix
Make MethodSecurityExpressionOperations createSecurityExpressionRoot(Supplier<Authentication> authentication, MethodInvocation invocation) protected instead of private

Sample
See - DefaultMethodSecurityExpressionHandler for the code in question

[jzheaux]

@adase11, thanks for the report.

These days, Spring Security tends to prefer encouraging composition, though changing a method to be protected is not out of the question. Can you please describe in more detail what you are trying to do and the result of trying the following to approaches:

1. Instead of extending DefaultMethodSecurityExpressionHandler, implement MethodSecurityExpressionHandler and call DefaultMethodSecurityExpressionHandler as a member variable.
2. Instead of customizing the expression handler, change your authorization expressions to refer to a bean that contains any specialized logic, for example @PreAuthorize("@myBean.authz(#root)")

[adase11]

Thanks @jzheaux - I'm migrating to Spring Security v5.8 from a Spring Boot 2.7.6 project in preparation for Spring Boot 3.0 & Spring Security 6. In the current app I overrode the DefaultMethodSecurityExpressionHandler:createSecurityExpressionRoot method in order to use a custom SecurityExpressionRoot without having to rewrite most of the DefaultMethodSecurityExpressionHandler logic. Like so:

public class CustomMethodSecurityExpressionHandler extends DefaultMethodSecurityExpressionHandler {
	@Override
	protected MethodSecurityExpressionOperations createSecurityExpressionRoot(Authentication authentication, MethodInvocation invocation) {
		final CustomMethodSecurityExpressionRoot adminMethodSecurityExpressionRoot = new CustomMethodSecurityExpressionRoot(authentication,
				invocation);
		adminMethodSecurityExpressionRoot.setPermissionEvaluator(getPermissionEvaluator());
		adminMethodSecurityExpressionRoot.setTrustResolver(new AuthenticationTrustResolverImpl());
		adminMethodSecurityExpressionRoot.setRoleHierarchy(getRoleHierarchy());
		return adminMethodSecurityExpressionRoot;
	}
}

Now, because createEvaluationContext calls directly the new private overloaded version of createSecurityExpressionRoot that's been added this ^ will no longer work.

Your first suggestion, implementing MethodSecurityExpressionHandler and calling DefaultMethodSecurityExpressionHandler as a member variable, is the direction I was working with in the meantime. However, I thought it could be desirable treat both implementations with the same level of visibility especially now because createEvaluationContext calls the private method directly rather than the protected one and as a result, the strategy I mentioned above will no longer work to register a custom SecurityExpressionRoot and will show up as a runtime rather than compile time error.

[adase11]

Just to clarify I think that both of your suggestions would work. I appreciate the recommendations!

[paveljandejsek]

@adase11 Can you please share how did your solution with DefaultMethodSecurityExpressionHandler member variable works? I am facing the same problem, but cannot seem to find a working solution yet.

[adase11]

@paveljandejsek - I believe that the 2 options that @jzheaux mentioned are the best way to handle this. I chose to go with changing the authorization expressions to refer to bean that contains specialized logic which worked well for my use case.

If you require extending DefaultMethodSecurityExpressionHandler for some other reason though you could go with implementing MethodSecurityExpressionHandler and call DefaultMethodSecurityExpressionHandler as a member variable.

Or you could override both createEvaluationContext & createSecurityExpressionRoot and implement your own version of MethodSecurityEvaluationContext (extending MethodBasedEvaluationContext) with similar logic to the package private MethodSecurityEvaluationContext to like so:

@Override
public EvaluationContext createEvaluationContext(Supplier<Authentication> authentication, MethodInvocation invocation) {
	final MethodSecurityExpressionOperations root = createSecurityExpressionRootOverride(authentication);
	final MethodSecurityEvaluationContext ctx = new MethodSecurityEvaluationContext(root, invocation, getParameterNameDiscoverer());
	ctx.setBeanResolver(getBeanResolver());
	return ctx;
}

@Override
protected MethodSecurityExpressionOperations createSecurityExpressionRoot(Authentication authentication, MethodInvocation invocation) {
	return createSecurityExpressionRootOverride(() -> authentication);
}

private MethodSecurityExpressionOperations createSecurityExpressionRootOverride(Supplier<Authentication> authentication) {
	final CustomMethodSecurityExpressionRoot methodSecurityExpressionRoot = new MethodSecurityExpressionRoot(authentication);
	methodSecurityExpressionRoot.setPermissionEvaluator(getPermissionEvaluator());
	methodSecurityExpressionRoot.setTrustResolver(authenticationTrustResolver);
	methodSecurityExpressionRoot.setRoleHierarchy(getRoleHierarchy());
	return methodSecurityExpressionRoot;
}

In my opinion - these three options are listed from most to least desirable (where changing the authorization expressions to refer to bean that contains specialized logic is the most desirable). Hope that helps!

---

To extrapolate a bit further on my original proposal - This last solution would be cleaned up significantly if both signatures for createSecurityExpressionRoot were protected (because the currently protected one just calls the private one). If that was done then the code that I had posted above that originally overrode createSecurityExpressionRoot could be changed to override the new signature for the method - like so (By changing Authentication authentication to Supplier<Authentication> authentication:

public class CustomMethodSecurityExpressionHandler extends DefaultMethodSecurityExpressionHandler {
	@Override
	protected MethodSecurityExpressionOperations createSecurityExpressionRoot(Supplier<Authentication>  authentication, MethodInvocation invocation) {
		final CustomMethodSecurityExpressionRoot adminMethodSecurityExpressionRoot = new CustomMethodSecurityExpressionRoot(authentication,
				invocation);
		adminMethodSecurityExpressionRoot.setPermissionEvaluator(getPermissionEvaluator());
		adminMethodSecurityExpressionRoot.setTrustResolver(new AuthenticationTrustResolverImpl());
		adminMethodSecurityExpressionRoot.setRoleHierarchy(getRoleHierarchy());
		return adminMethodSecurityExpressionRoot;
	}
}

[adase11]

The member variable solution I was working on would look something like:

public class CustomMethodSecurityExpressionHandler extends AbstractSecurityExpressionHandler<MethodInvocation>
		implements MethodSecurityExpressionHandler {
	private final DefaultMethodSecurityExpressionHandler delegate = new DefaultMethodSecurityExpressionHandler();

	@Override
	public Object filter(Object filterTarget, Expression filterExpression, EvaluationContext ctx) {
		return delegate.filter(filterTarget, filterExpression, ctx);
	}
	
	...
}

I had not yet tested to ensure feature parity