If you manually define both a RoleHierarchy bean and a MethodSecurityExpressionHandler, the RoleHierarchy isn't injected in the MethodSecurityExpressionHandler bean. As a result, the role hierarchy isn't applied when calling hasRole() when securing a method with @PreAuthorize.

To Reproduce 1. Define a RoleHierarchy bean 2. Manually define the bean for the MethodSecurityExpressionHandler. For example, by inheriting DefaultMethodSecurityExpressionHandler.

Expected behavior The RoleHierarchy bean is injected in the manually defined MethodSecurityExpressionHandler and can be used with @PreAuthorize and hasRole()

Current behavior When you launch the application the following happens in order: 1. PrePostMethodSecurityConfiguration initialize expressionHandler with a manually created DefaultMethodSecurityExpressionHandler 2. The RoleHierarchy bean is injected in PrePostMethodSecurityConfiguration and expressionHandler.setRoleHierarchy is called 3. The manually defined MethodSecurityExpressionHandler. bean is injected in PrePostMethodSecurityConfiguration and the configuration is adapted, but the method setRoleHierarchy isn't called on the new bean.

Comment From: jzheaux

Can you please post some code to help me see what code you'd expect to work?

Comment From: kse-music

I think when provide custom MethodSecurityExpressionHandler bean and some other bean that include not only RoleHierarchy but also GrantedAuthorityDefaults, ApplicationContext, etc, we need to provide full function bean like this.

  @Bean
    MethodSecurityExpressionHandler customMethodSecurityExpressionHandler(RoleHierarchy roleHierarchy) {
        DefaultMethodSecurityExpressionHandler expressionHandler = new DefaultMethodSecurityExpressionHandler();
        expressionHandler.setRoleHierarchy(roleHierarchy);
        expressionHandler.setDefaultRolePrefix("...");
    this.expressionHandler.setApplicationContext(context);
        return expressionHandler;
    }

Additionally, when both a custom MethodSecurityExpressionHandler and RoleHierarchy are provided, is it necessary to configure them within the framework? @jzheaux

Comment From: jzheaux

You are correct, @kse-music, this is covered in the reference specifically with respect to RoleHierarchy.

Since RoleHierarchy is used in multiple places, it should be published as a bean. This allows all Spring Security components to pick it up and then evaluate roles in the same way.

That said, I'd still like to give @plumarr the opportunity to respond in case I haven't correctly understood their question.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-projects-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

Comment From: plumarr

Sorry for the delay, I was on holiday for Christmas and New year.

@kse-music understranding of the issue is the correct one.

Do you still need a minimum reproduction code ?