@RolesAllowed vs. @PreAuthorize vs. @Secured
@Secured
and @RolesAllowed
perform identical functionality in Spring. The difference is that @Secured
is a Spring specific annotaiton while @RolesAllowed
is a Java standard annotation (JSR250). Neither one of these 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 the limit method invocation based on the roles/permissions, the current authenticated user, and the arguments passed into the method.
@PreAuthorize("hasRole('ADMIN') or #user.id == authentication.name")
public void deleteUser(User user) {
...
}
http://docs.spring.io/autorepo/docs/spring-security/4.0.x/reference/html/el-access.html#el-common-built-in
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
.
All of these are basically the same for your purpose, but @PreAuthorize
is the best fit for controllers and controller methods. @Secured
and @RolesAllowed
are intended for describing service layer security attributes.
Also be aware for @PreAuthorize
annotation to work you must define a configuration class:
@Configuration
@EnableGlobalMethodSecurity(prePostEnabled = true)
public class MethodSecurityConfig extends GlobalMethodSecurityConfiguration {
...
}
Security Annotations
All of @PreAuthorize
, @RolesAllowed
and @Secured
are annotations which allow to configure method security. They can be applied both on individual methods or on 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
@PreAuthorize
annotation allows to specify 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 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
@EnableGlobalMethodSecurity
annotation needs to be set to true
:
@EnableGlobalMethodSecurity(prePostEnabled=true)
@RolesAllowed
@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 Spring Expression Language (SpEL) 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)
Which security annotations allow to use SpEL
The following table shows the support for Spring Expression Language in the security annotations that can be used with Spring Security 5:
╔═════════════════════╦═══════════════════╗
║ Security Annotation ║ Has SpEL Support? ║
╠═════════════════════╬═══════════════════╣
║ @PreAuthorize ║ yes ║
╠═════════════════════╬═══════════════════╣
║ @PostAuthorize ║ yes ║
╠═════════════════════╬═══════════════════╣
║ @PreFilter ║ yes ║
╠═════════════════════╬═══════════════════╣
║ @PostFilter ║ yes ║
╠═════════════════════╬═══════════════════╣
║ @Secured ║ no ║
╠═════════════════════╬═══════════════════╣
║ @RolesAllowed ║ no ║
╚═════════════════════╩═══════════════════╝