Spring Security 3 - MVC: Using Native Expression-Based Annotation Tutorial

In this tutorial we will build a simple Spring MVC 3 application and provide security using Spring Security 3. We will use Spring Security's native, expression-based annotation to secure parts of our application. Our users will be authenticated based on Spring's built-in in-memory user-service. This tutorial is exactly similar with Spring Security 3 - MVC: Using @Secured Annotation Tutorial. The main difference is the type of annotations they use.

What is Spring Security?

Spring Security is a powerful and highly customizable authentication and access-control framework. It is the de-facto standard for securing Spring-based applications

Spring Security is one of the most mature and widely used Spring projects. Founded in 2003 and actively maintained by SpringSource since, today it is used to secure numerous demanding environments including government agencies, military applications and central banks. It is released under an Apache 2.0 license so you can confidently use it in your projects.

Source: Spring Security

What is Spring Security's native, expression-based annotation?

From 3.0 you can also make use of new expression-based annotations.

Source: Spring Security 3.1 Reference 2.4 Method Security

Spring Security 3.0 introduced the ability to use Spring EL expressions as an authorization mechanism in addition to the simple use of configuration attributes and access-decision voters which have seen before. Expression-based access control is built on the same architecture but allows complicated boolean logic to be encapsulated in a single expression

Source: Spring Security 3.1 Reference 15. Expression-Based Access Control

There are four annotations which support expression attributes to allow pre and post-invocation authorization checks and also to support filtering of submitted collection arguments or return values. They are @PreAuthorize, @PreFilter, @PostAuthorize and @PostFilter. Their use is enabled through the global-method-security namespace element

Source: Spring Security 3.1 Reference 15.3. Method Security Expressions

These annotations allow you to put restrictions in your methods. For example, you can authorize a get() method to be accessible by all registered users. But for the edit() method, you can mark it be accessible by admins only. What's the difference between these annotations and the @Secured? These expression-based annotations allow you to setup complicated logic that's not possible with @Secured alone.

For example, we can mark a method to be accessible only if a certain condition exist:

This expression means allow this method to be accessible only when the person's id is equal to the number 3. It doesn't matter if you're admin or regular user. As long as the id is equal to 3, you're good to go. We'll explore this feature more in our upcoming tutorials.

Let's go back to the main purpose of this tutorial that is to create a Spring MVC application with Spring Security integrated using the native, expression-based annotations. For this matter, we'll focus on the @PreAuthorize because of its similarity with the @Secured.

We'll build first the Spring MVC part of our application, then add Spring Security. Our application has an admin and common pages. It also has a view to show all persons. Only admins can edit a person's record.

Let's declare our primary controller first.

MainController

This controller declares two mappings:

/main/common - any registered user can access this page
/main/admin - only admins can access this page

Each mapping will resolve to a specific JSP page. The common JSP page is accessible by everyone, while the admin page is accessible only by admins. Right now, everyone has access to these pages because we haven't enabled Spring Security yet.

Notice we've annotated each method with @PreAuthorize annotation. For the getAdminPage(), we put

@PreAuthorize("hasAuthority('ROLE_ADMIN')")

and for the getCommonPage(), we put

@PreAuthorize("hasAuthority('ROLE_USER')")

. Once we activated Spring Security these annotations will take effect.

Here are the JSP pages:

commonpage.jsp



adminpage.jsp



We've finished setting-up the primary controller and the associated JSP views. Now, we add the required XML configurations to enable Spring MVC and Spring Security at the same time.

We start by adding the web.xml:

web.xml

Notice the url-patterns for the DelegatingFilterProxy and DispatcherServlet. Spring Security is placed at the root-path

/*

Whereas, Spring MVC is placed at a sub-path

/krams/*

We also referenced two important XML configuration files:

spring-security.xml 
applicationContext.xml

spring-security.xml contains configuration related to Spring Security.

spring-security.xml

The elements are self-documenting. If you're using an IDE, like Eclipse or STS, try pointing your mouse to any of these elements and you will see a short description of the element.

Notice that the bulk of the security configuration is inside the http element. Here's what we observe:

1. We enabled @PreAuthorize, @PreFilter, @PostAuthorize and @PostFilter annotations by adding the global-method-security tag:

2. We declared the denied page URL in the

access-denied-page="/krams/auth/denied"

3. We declared the login URL

login-page="/krams/auth/login"

4. We declared the login failure URL

authentication-failure-url="/krams/auth/login?error=true"

5. We declared the URL where the user will be redirected if he logs out

logout-success-url="/krams/auth/login"

6. We declared the logout URL

logout-url="/krams/auth/logout"

7. We declared a default authentication-manager that references an in-memory user-service

8. We declared an in-memory user-service:

This basically declares two users with corresponding passwords and authorities. This user-service is a good way to prototype and test a Spring Security application quickly.

9. We also declared an Md5 password encoder:

When a user enters his password, it's plain string. The password we have in our database (in this case, an in-memory lists) is Md5 encoded. In order for Spring to match the passwords, it's need to encode the plain string to Md5. Once it has been encoded, then it can compare passwords.

Compare this configuration with the one declared in Spring Security 3 - MVC: Using a Simple User-Service Tutorial. Our current configuration is missing the following declaration:

We don't need to declare those intercept-urls anymore because we've already annotated the methods that corresponds to those URLs. You can actually mix them if you need to.

Now we need to create a special controller that handles the login and logout requests.

LoginLogoutController

This controller declares two mappings:

/auth/login - shows the login page
/auth/denied - shows the denied access page

Each mapping will resolve to a specific JSP page.

Here are the JSP pages:

loginpage.jsp



deniedpage.jsp



That's it. We got a working Spring MVC 3 application that's secured by Spring Security. We've managed to build a simple and quick Spring Security configuration.

To access the common page, enter the following URL:

http://localhost:8080/spring-security-annotation-native/krams/main/common

To access the admin page, enter the following URL:

http://localhost:8080/spring-security-annotation-native/krams/main/admin

To login, enter the following URL:

http://localhost:8080/spring-security-annotation-native/krams/auth/login

To logout, enter the following URL:

http://localhost:8080/spring-security-annotation-native/krams/auth/logout

But there's more! Notice we annotated the methods from our controller. What will happen if we annotate the methods of our services instead?

To explore this inquiry, we will provide a hypothetical business scenario. Our client needs to view a list of persons. All registered users can view this list, but only admins can edit it.

We start by declaring a controller.

PersonController


In this controller we have three mappings:

/main - retrieve all persons
/main/edit/{id} - (GET) retrieve and edit a person by his id 
/main/edit/{id} - (POST) save a person based on his id

Notice we have two /main/edit/{id}. How does our controller know which one to call? The controller's @RequestMapping doesn't just rely on the mapping value but it also uses the method type. In our case, it's either POST or GET. The GET method is used when we retrieve a page; whereas, the POST method is used when we're submitting a form. For more info, please check the following blog from SpringSource Annotated Web MVC Controllers in Spring 2.5.

Also, we're using a special identifier in the mappings. We have declared a {id} in the path, and referenced that as @PathVariable in the method parameter. This is a URI template, one of the RESTful features of Spring 3 MVC.

What is a URI template?

A URI template is a URI-like string, containing one or more variable names. When these variables are substituted for values, the template becomes a URI. For more information, see the proposed RFC.

Source: REST in Spring 3: @MVC

For a thorough description of this subject, please visit the blog from SpringSourceREST in Spring 3: @MVC

It's worth noting that we did not annotate this controller with @Secured annotation.

Let's examine the associated JSP view for each mappings.

personspage.jsp

This is referenced by the mapping /persons.

To access the persons page, type the following URL in the browser:

http://localhost:8080/spring-security-annotation-native/krams/persons

editpage.jsp

This is referenced by the mapping /persons/edit/{id} (GET)

To access the edit page, we need to manually type the following URL in the browser:

http://localhost:8080/spring-security-annotation-native/krams/persons/edit/2

Just make sure to change the number to match the id that you want to edit.

Now let's define our service. Remember we referenced a PersonService in the PersonController.

PersonService

Pay attention to the methods. We've annotated the methods with @PreAuthorize.

getAll() and get() has been assigned with ROLE_USER. This means all registered users can access these methods.

edit() has been assigned with ROLE_ADMIN. This means only admins can access this method.

If you need to test these methods, try logging-in as john (password is admin) and as jane (password is user). Both users can view the list of persons. Both users can access the edit page. But only john can do a successful edit, while jane will get the following message

HTTP Status 405 - Request method 'POST not supported'

The best way to learn further is to try the actual application.

Download the project
You can access the project site at Google's Project Hosting at http://code.google.com/p/spring3-security-mvc-integration-tutorial/

You can download the project as a Maven build. Look for the spring-security-annotation-native.zip in the Download sections.

You can run the project directly using an embedded server via Maven.
For Tomcat: mvn tomcat:run
For Jetty: mvn jetty:run

---

Share the joy: blogger tutorials Social Bookmarking Blogger Widget I'm reading: Spring Security 3 - MVC: Using Native Expression-Based Annotation Tutorial ~

Subscribe by reader Subscribe by email Share