Spring Security SEC-2989: DefaultMethodSecurityExpressionHandler should use the rolePrefix set in RoleHierarchy when available.

Srikara Rao (Migrated from SEC-2989) said:

We ran into this issue as we upgraded from version 3.2.7 to 4.0.1. In version 3.2.7 of DefaultMethodSecurityExpressionHandler there is no defaultRolePrefix set in the handler.

    protected MethodSecurityExpressionOperations createSecurityExpressionRoot(Authentication authentication, MethodInvocation invocation) {
        MethodSecurityExpressionRoot root = new MethodSecurityExpressionRoot(authentication);
        root.setThis(invocation.getThis());
        root.setPermissionEvaluator(getPermissionEvaluator());
        root.setTrustResolver(trustResolver);
        root.setRoleHierarchy(getRoleHierarchy());

        return root;
    }

However, this changes in 4.0.1 to

protected MethodSecurityExpressionOperations createSecurityExpressionRoot(
            Authentication authentication, MethodInvocation invocation) {
        MethodSecurityExpressionRoot root = new MethodSecurityExpressionRoot(
                authentication);
        root.setThis(invocation.getThis());
        root.setPermissionEvaluator(getPermissionEvaluator());
        root.setTrustResolver(trustResolver);
        root.setRoleHierarchy(getRoleHierarchy());
        {color:#d04437}root.setDefaultRolePrefix(defaultRolePrefix);{color}

        return root;
    }

If we have a custom role hierarchy with a different role prefix defined in the RoleHierarchy, this results in a 403 every time.

Proposed Fix: If there is a valid RoleHierarchy set, DefaultMethodSecurityExpressionHandler should be using the role prefix defined in the supplied RoleHierarchy.

If the desired behavior is to have the developers set the role prefix at both the locations, then please feel free to close the bug.

Comment From: spring-projects-issues

Srikara Rao said:

bump

Comment From: marcusdacoregio

I did not find a way to set the role prefix in the RoleHierarchy class, so I assume there is no way to set the role prefix there instead of DefaultMethodSecurityExpressionHandler. I'm closing this but if someone can clarify how this suggestion would work in the absence of a way to get the prefix it is okay to reopen.