Spring Security 3 - MVC: Using @Secured Annotation Tutorial

In this tutorial we will build a simple Spring MVC 3 application and provide security using Spring Security 3. We will use @Secured annotation to secure parts of our application. Our users will be authenticated based on Spring's built-in in-memory user-service.

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 @Secured annotation?

From version 2.0 onwards Spring Security has improved support substantially for adding security to your service layer methods. It provides support for JSR-250 annotation security as well as the framework's original @Secured annotation.

Source: Spring Security 3.1 Reference 2.4 Method Security

@Secured annotation allows 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.

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 @Secured annotation. For the getAdminPage(), we put

@Secured("ROLE_ADMIN")

and for the getCommonPage(), we put

@Secured("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 @Secured annotation 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-secured/krams/main/common

To access the admin page, enter the following URL:

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

To login, enter the following URL:

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

To logout, enter the following URL:

http://localhost:8080/spring-security-annotation-secured/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-secured/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-secured/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 @Secured.

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-secured.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 @Secured Annotation Tutorial ~

Subscribe by reader Subscribe by email Share