Spring Security: @RolesAllowed vs @PreAuthorize vs @Secured

Spring Security Method Level Security: What are the differences between these three annotations?

For Java-based applications, Spring Security is a strong and highly flexible authentication and access-control framework. Method-level security, commonly referred to as method-level security, is one element of Spring Security. Instead of imposing security constraints on the entire class or application, method-level security enables developers to impose security limitations on specific methods within a class. This enables more precise control over who has access to particular areas of the program annotations.

Using the Annotations For Method Level Security.

All of @PreAuthorize@RolesAllowed and @Secured are annotations that allow configuring method security in spring. They can be applied both on individual methods or on the class level, in the latter case the security constraints will be applied to all methods in the class.

Method-level security is accomplished using Spring AOP proxies.

@PreAuthorize

The @PreAuthorize annotation allows specifying access constraints to a method using the Spring Expression Language (SpEL). These constraints are evaluated prior to the method being executed and may result in the execution of the method being denied if the constraints are not fulfilled. The @PreAuthorize annotation is part of the Spring Security framework.

In order to be able to use @PreAuthorize, the prePostEnabled  attribute in the  @EnableMethodSecurity annotation needs to be set to true:

 

@EnableMethodSecurity(prePostEnabled=true)

@RolesAllowed

The @RolesAllowed annotation has its origin in the JSR-250 Java security standard. This annotation is more limited than the @PreAuthorize annotation because it only supports role-based security.

In order to use the @RolesAllowed annotation the library containing this annotation needs to be on the classpath, as it is not part of Spring Security. In addition, the jsr250Enabled attribute of the @EnableGlobalMethodSecurity annotation need to be set to true:

@EnableGlobalMethodSecurity(jsr250Enabled=true)

@Secured

@Secured annotation is a legacy Spring Security 2 annotation that can be used to configure method security. It supports more than only role-based security but does not support using

The @PreAuthorize annotation allows specifying access constraints to a method using the Spring Expression Language (SpEL). These constraints are evaluated prior to the method being executed and may result in the execution of the method being denied if the constraints are not fulfilled.

The @PreAuthorize annotation is part of the Spring Security framework.

to specify security constraints. It is recommended to use the @PreAuthorize annotation in new applications over this annotation.

Support for the @Secured annotation needs to be explicitly enabled in the  @EnableGlobalMethodSecurity annotation using the securedEnabled attribute:

@EnableGlobalMethodSecurity(securedEnabled=true)

 

@Secured and @RolesAllowed perform identical functionality in Spring. The difference is that @Secured is a Spring-specific annotation while @RolesAllowed is a Java standard annotation (JSR250). Neither one of this annotation support SpEL.

@PreAuthorize is another Spring specific annotation. You can perform a lot more powerful operations with @PreAuthorize using SpEL. You can write expressions for the limit method invocation based on the roles/permissions, the currently authenticated user, and the arguments passed into the method.

Example:

@PreAuthorize("hasRole('ADMIN') or #user.id == authentication.name")
public void deleteUser(User user) {
    ...
}

As you can notice from the delete method above, this method can only be invoked by any user with the ROLE of ADMIN or the currently logged-in user Id must be == the user Id to be deleted ( this means no user should be able to delete another user except the Admin).

Conclusion

As for which to use, it’s really up to you. @Secure and @PreAuthorize will tie your code to Spring. If being tied to Spring is not an issue or you need to perform more powerful operations, use @PreAuthorize.

Original Source Here…