How to check security acess (@Secured or @PreAuthorize) before validation (@Valid) in my Controller?

Question

here is my Controller code :

@PreAuthorize("hasRole('CREATE_USER')")
@RequestMapping(method = RequestMethod.POST, produces = MediaType.APPLICATION_JSON_VALUE, consumes = MediaType.APPLICATION_JSON_VALUE)
@ResponseBody
public UserReturnRO createUser(@Valid @RequestBody UserRO userRO) throws BadParameterException{

    return userService.createUser(userRO);
}

My need is when a client without the appropriate role tries to create a user, the controller responds "Not authorized" even if the data sent are not valid. Instead of that, if the client (without the appropriate role) tries to create a user with wrong data, my controller responds with the @Valid message (ex : "password cannot be empty"), while I want it responds "not authorized".

In the PreAuthorized Interface we can find this sentence :

Annotation for specifying a method access-control expression which will be evaluated to decide whether a method invocation is allowed or not.

but it seems that it's not the case.

Santee

The validation errors ALSO happen outside of the method - they are triggered by that Valid annotation which is - just like PreAuthorize - evaluated before the method is entered. i am not sure if it is possible to change the order there? my guess is - no. why would you want the 403 in either case? – Coracorabel

because I don't want an not-authorized-user to access to the validation rules – Santee

ok. i wonder if @PreAuthorize would work if you put it on the validator? – Coracorabel

Spring team already know this issue github.com/spring-projects/spring-boot/issues/10157 – Sidero

Answer 1

You can not do this directly, since @Valid is processed before an actual method call and as a result before @PreAuthorize.

But what you can do instead is to inject BindingResult just right after your model (userRO) and in doing so - take control of validation process. Then check if BindingResult has some errors and if so return bad request response (similar to what spring does).

Example:

@ResponseBody
@RequestMapping(method = RequestMethod.POST, produces = MediaType.APPLICATION_JSON_VALUE, consumes = MediaType.APPLICATION_JSON_VALUE)
@PreAuthorize("hasRole('CREATE_USER')")
public ResponseEntity<?> createUser(@RequestBody @Valid UserRO userRO, BindingResult result) {
    if (result.hasErrors()) {
        return ResponseEntity.badRequest().body(result.getAllErrors());
    }
    return ResponseEntity.ok(userService.createUser(userRO));
}

Spirt

Works like a charm, but this behavior is absolutely weird (didn't they say "security first" ?). – Publican

2023 still working, but still a strange solution to a strange problem. On the other, hand it just hides the request body validation error. – Pivotal

Answer 2

As already stated, Spring Security's @PreAuthorize is method advice, which means that it does not get to participate until the method and its arguments have already been resolved.

Aside from the answer already given, there are a few ways to move authorization before argument resolution, instead.

Filter Security

First, Spring Security checks URLs before the request is mapped to a method. And since this is a @Controller, it's reasonable to suppose that you could instead map the request to the role at that level instead of @PreAuthorize:

http
    .authorizeRequests()
        .mvcMatchers(POST, "/somepath").hasRole("CREATE_USER")

Handler Interceptor

Second, Spring MVC does ship with limited support for checking authorities before parsing method arguments. For example, you can do:

@EnableWebMvc
public static class MvcConfig implements WebMvcConfigurer {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        UserRoleAuthorizationInterceptor userRole =
            new UserRoleAuthorizationInterceptor();
        userRole.setAuthorizedRoles("CREATE_USER");
        registry.addInterceptor(userRole);
    }
}

This is much more basic than @PreAuthorize since it's a global setting, but I've included it for completeness.

Handler Interceptor, Part 2

Third (warning, some inelegance ahead), you can create your own HandlerInterceptor.

The flow is:

1. FilterSecurityInterceptor <== where .mvcMatchers(...).hasRole(...) lives
2. Then HandlerInterceptors
3. Then argument validation
4. Then MethodSecurityInterceptor <== where @PreAuthorize lives

So, your HandlerInterceptor would check before arguments are resolved. It doesn't have to be as involved as MethodSecurityInterceptor, though. It could, for example, simply be:

static class AuthorizationInterceptor extends HandlerInterceptorAdapter {
    SecurityMetadataSource securityMetadataSource;
    AccessDecisionManager accessDecisionManager;

    @Override
    public void preHandle(HttpServletRequest request,
        HttpServletResponse response, Object handler) {

        Authentication authenticated = (Authentication) request.getUserPrincipal();
        MethodInvocation mi = convert(handler);
        Collection<ConfigAttribute> attributes =
            this.securityMetadataSource.getAttributes(mi);

        // throws AccessDeniedException
        this.accessDecisionManager.decide(authenticated, mi, attributes);
        return true;
    }
}

Then you wire it together with:

@EnableGlobalMethodSecurity(prePostEnabled = true)
static class MethodConfig extends GlobalMethodSecurityConfiguration {
    @Bean
    HandlerInterceptor preAuthorize() throws Exception {
        return new AuthorizationInterceptor(
            accessDecisionManager(), methodSecurityMetadataSource());
    }
}

@EnableWebMvc
public static class MvcConfig implements WebMvcConfigurer {
    @Autowired
    AuthorizationInterceptor authorizationInterceptor;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(authorizationInterceptor);
    }
}

It's inelegant because MethodSecurityInterceptor would still participate in authorized requests, which would ostensibly be the majority.

Gabrielgabriela