Setting up the sample

This section outlines how to setup a workspace within Spring Tool Suite (STS) so that you can follow along with this guide. The next section outlines generic steps for how to apply Spring Security to your existing application. While you could simply apply the steps to your existing application, we encourage you to follow along with this guide as is to reduce the complexity.

Obtaining the sample projects

Import the insecuremvc sample application

In order to follow along, we encourage you to import the insecuremvc sample application into your IDE. You may use any IDE you prefer, but the instructions in the guide will assume you are using Spring Tool Suite (STS).

The completed sample application can be found at SPRING_SECURITY_HOME/samples/hellomvc-jc

Start STS and import the sample applications into STS using the following steps:

File→Import

Existing Maven Projects

Click Next >

Click Browse…

Navigate to the samples (i.e. SPRING_SECURITY_HOME/samples/insecuremvc) and click OK

Click Finish

Running the insecuremvc application

In the following exercise we will be modifying the spring-security-samples-insecuremvc application. Before we make any changes, it is best to verify that the sample works properly. Perform the following steps to ensure that spring-security-samples-insecuremvc works.

Try clicking on the Compose link and creating a message. The message details should be displayed.

Now click on the Inbox link and see the message listed. You can click on the summary link to see the details displayed again.

Securing the application

Before securing your application, it is important to ensure that the existing application works as we did in Running the insecuremvc application. Now that the application runs without security, we are ready to add security to our application. This section demonstrates the minimal steps to add Spring Security to our application.

Updating your dependencies

In order to resolve Spring Security SNAPSHOT dependencies add the Spring Snapshot repository. For our example, the repository has already been added for you. In the event you were working on another application, you would need to ensure you add the following to your pom:

The name of the configureGlobal method is not important. However, it is important to only configure AuthenticationManagerBuilder in a class annotated with either @EnableWebSecurity, @EnableWebMvcSecurity, @EnableGlobalMethodSecurity, or @EnableGlobalAuthentication. Doing otherwise has unpredictable results.

The MessageSecurityWebApplicationInitializer will automatically register the springSecurityFilterChain Filter for every URL in your application. If Filters are added within other WebApplicationInitializer instances we can use @Order to control the ordering of the Filter instances.

Verify SecurityConfig is loaded

Just because SecurityConfig exists, does not mean that our Spring application knows about it. In this instance, our Spring root application context is initialized using MessageWebApplicationInitializer which is included with our spring-security-samples-messages-jc project. You can find a snippet of it below:

You will notice it is loading the RootConfiguration class which is also included in our spring-security-samples-messages-jc project.

RootConfiguration.java

@Configuration
@ComponentScan
public class RootConfiguration {
}

The @ComponentScan is loading all configuration within the same package (and child packages) as RootConfiguration. Since SecurityConfig is in this package, it will be loaded with our existing setup and there is nothing more to do.

In our samples we use Thymeleaf, but any view technology will work. Any technology can inspect the HttpServletRequest#getRemoteUser() to view the current user since Spring Security integrates with the Servlet API methods.

The Thymeleaf ensures the username is escaped to avoid XSS vulnerabilities Regardless of how an application renders user inputed values, it should ensure that the values are properly escaped.

Logging out

We can view the user name, but how are we able to log out? Below you can see how we are able to log out.

If you try to log out right now the request will fail. The reason is that Spring Security is protecting against CSRF attacks and there is no CSRF token include in our request. Update our configuration to use the @EnableWebMvcSecurity annotation which will do the same as @EnableWebSecurity and provide integration with Spring MVC. Among other things, it will ensure our CSRF Token is included in our forms automatically when using Thymleaf 2.1+ or Spring MVC taglibs.

In order to help protect against CSRF attacks, by default, Spring Security Java Configuration log out requires:

the HTTP method must be a POST

the CSRF token must be added to the request. Since we have used @EnableWebMvcSecurity and are using Thymeleaf, the CSRF token is automatically added as a hidden input for you (view the source to see it).

If you were not using Spring MVC taglibs or Thymeleaf, you can access the CsrfToken on the ServletRequest using the attribute _csrf. You can find an example of including the CSRF token in a JSP within the Hello Spring Security Java Config.

Restart the application server and click the Log out button and see that the application logs you out successfully.

Conclusion

You should now know how to secure your application using Spring Security without using any XML. Next, we will see how to customize our login form.