Spring Security 4 Method security using @PreAuthorize,@PostAuthorize, @Secured, EL--转

原文地址：http://websystique.com/spring-security/spring-security-4-method-security-using-preauthorize-postauthorize-secured-el/

In order to enable Spring Method level Security, we need to annotate a @Configuration class with

@EnableGlobalMethodSecurity

, as shown below:

@EnableGlobalMethodSecurity enables Spring Security global method security similar to the in XML configurations like shown below:

Note that @EnableGlobalMethodSecurity can take several arguments, some are shown below:

prePostEnabled :Determines if Spring Security’s pre post annotations [@PreAuthorize,@PostAuthorize,..] should be enabled.

secureEnabled : Determines if Spring Security’s secured annotation [@Secured] should be enabled.

jsr250Enabled : Determines if JSR-250 annotations [@RolesAllowed..] should be enabled.

You can enable more than one type of annotation in the same application, but only one type should be used for any interface or class as the behavior will not be well-defined otherwise. If two annotations are found which apply to a particular method, then only one of them will be applied.

We will explore first two of above mentioned in detail.

@Secured

@Secured annotation is used to define a list of security configuration attributes for business methods. You can specify the security requirements[roles/permission etc] on a method using @Secured, and than only the user with those roles/permissions can invoke that method. If anyone tries to invoke a method and does not possess the required roles/permissions, an AccessDenied exception will be thrown.

@Secured is coming from previous versions of Spring. It has a limitation that it does not support Spring EL expressions. Consider following example:

In above example, updateUser method can be invoked by someone with ADMIN role while deleteUser can be invoked by anyone with DBA OR ADMIN role. If anyone tries to invoke a method and does not possess the required role, an AccessDenied exception will be thrown.

What if you want to specify an ‘AND’ condition. I mean , you want deleteUser method to be invoked by a user who have both ADMIN & DBA role. This is not possible straight-away with @Secured annotation.

This can however be done using Spring’s new @PreAuthorize/@PostAuthorize annotations which supports Spring EL, that means possibilities are unlimited.

@PreAuthorize / @PostAuthorize

Spring’s

@PreAuthorize/@PostAuthorize

annotations are preferred way for applying method-level security, and supports Spring Expression Language out of the box, and provide expression-based access control.

@PreAuthorize is suitable for verifying authorization before entering into method. @PreAuthorize can take into account, the roles/permissions of logged-in User, argument passed to the method etc.

@PostAuthorize , not often used though, checks for authorization after method have been executed, so it is suitable for verifying authorization on returned values. Spring EL provides returnObject object that can be accessed in expression language and reflects the actual object returned from method.

Please refer to Common Built-In Expressions to get the complete list of supported expressions.

Let’s get back to our example, this time using @PreAuthorize / @PostAuthorize.

Since @PreAuthorize can use Spring Expression Language, any condition can easily be expressed using EL. Method deleteUser is now configured to be invoked by a user who have both ADMIN & DBA roles.

Additionally, we have added a method findById() with @PostAuthorize annotation. With @PostAuthorize, the returned value from the method(User object) will be accessible with

returnObject

in Spring Expression Language, and individual properties of return user object can be used to apply some security rules. In this example we are making sure that a logged-in user can only get it’s own User type object.

That’s all about basic usage of @Secured, @PreAuthorize, @PostAuthorize and EL.

Below mentioned is service implementation, User model class & Controller, used in this example.

Complete code for this example is attached at the end of this post.

Deploy & Run

Download complete code example attached at the end of post. Deploy it on Servlet 3.0 container(Tomcat 8.0.21 e.g.).
Open browser and goto http://localhost:8080/SpringSecurityMethodLevelSecurityAnnotationExample/, you will be prompted for login. Fill in USER role credentials.



Submit, you will see list of users.



Now try to edit or delete a users, you should see accessDenied page, because USER role does not have access to these functions.



Logout. Login with ADMIN role credentials.



Submit, you will see list of users.



Now click on edit for first row [with type='admin']. Edit page should be presented.



Now go back to list of item and click on third row [with type = 'dba']



You got accessDenied because during edit, function findById gets called which is annotated with @PostAuthorize annotation with EL restricting the returned object to be only with type['dba'] same as logged-in user name.

Now click on any delete row, accessDenied should be shown as deleteUser is only allowed for role ‘DBA’.



Now logout, login with DBA role [dba,root123], and click on delete link of first row. Row should be deleted successfully.



That’s it.