DefaultMethodSecurityExpressionHandler createSecurityExpressionRoot Should Have Protected Access Instead Of Private

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]

I’ve added https://github.com/spring-projects/spring-security/issues/12356 to provide more detail on the migration steps for DefaultMethodSecurityExpressionHandler usage.

Given that, I’ll close this ticket. @paveljandejsek, please try the migration guide once that ticket is complete. If the migration steps don’t work for you, we can come back here and revisit.

[jzheaux]

Another option I believe is to extend the createEvaluationContext method itself, like so:

@Component
public class MyExpressionHandler extends DefaultMethodSecurityExpressionHandler {
    @Override 
    public EvaluationContext createEvaluationContext(Supplier<Authentication> authentication, MethodInvocation mi) {
        CustomMethodSecurityExpressionRoot adminMethodSecurityExpressionRoot = 
                new CustomMethodSecurityExpressionRoot(authentication,	invocation);
	adminMethodSecurityExpressionRoot.setPermissionEvaluator(getPermissionEvaluator());
	adminMethodSecurityExpressionRoot.setTrustResolver(new AuthenticationTrustResolverImpl());
	adminMethodSecurityExpressionRoot.setRoleHierarchy(getRoleHierarchy());
        StandardEvaluationContext context = (StandardEvaluationContext) super.createEvaluationContext(authentication, mi);
        context.setRootObject(adminMethodSecurityExpressionRoot);
        return context;
    }
}

As @adase11 has already found, using a custom bean in the annotation expression is often preferrable.