Spring Security part I : Configuration & Security Chain

In this series of articles we’ll dig into the Spring Security framework.

Spring Security can be considered as a flexible and portable security manager. It is a real alternative to built-in security manager available on many application servers.

All transversal tasks related to security management (login, logout, authentication, authorization …) usually handled by the application server can be delegated to Spring Security. It helps decoupling the application logic & security management from the proprietary security implementation provided by different JEE application servers.

I Installation

To enable Spring Security, you should add the following jar as Maven dependency to your project:


It is strongly recommended to create a separate spring-security.xml configuration file to manage all beans related to the security aspect.

In the web.xml file, Spring’s DelegatingFilterProxy class should be declared as a servlet filter


and declared as the first filter in the to secure all the filter chain.


Please notice that the property <filter-name> should point to a valid bean id in the Spring context.

II Overview

The security management process comes down to the following aspects:

  1. Security chain: to be able to secure an application, we should clearly define a security chain with an entry and exit point. Every resource inside this chain will be secured according to user defined rules. The security chain is the main entry point for Spring Security
  2. Login/Logout: any decent security framework should provides a consistent way to handle login & logout events
  3. Authentication: during this step, the framework tries to identify the end user with the provided credentials. The authentication can be done against a third party system plugged into Spring Security
  4. Anonymous role: it is sometimes necessary to allow unsecured access to some resources (such as style sheet, image, login page …). In this case the anonymous role management is required
  5. Exception handling: a robust security system should provide a clean way to handle exceptions (invalid login/password, access denied …)
  6. Access management: in this step the framework will grant or deny access to requested resources based on the roles/authorities granted to the user. These authorities(roles) are determined at the Authentication step


III Security Chain

Let’s have a closer look into the spring-security.xml configuration file

	<bean id="filterChainProxy" class="org.springframework.security.web.FilterChainProxy">
		<sec:filter-chain-map path-type="ant">
		    <sec:filter-chain pattern="/webServices/**" filters="
		           filterSecurityInterceptor" />
		    <sec:filter-chain pattern="/**"  filters="
		           filterSecurityInterceptor" />

First, the id of the FilterChainProxy bean is set to filterChainProxy. This id is also the filter name of the Spring’s DelegatingFilterProxy declared previously in the web.xml file. It is the default convention.

Next, the <filter-chain-map> allows to match a particular path pattern agains a security filter chain defined in <filter-chain> tag.

The path pattern can be expressed using Ant style or regular expression and is configured by the propery path-type.

You can set as many filter chains as there are different path patterns. In the above configuration, we have a filter chain dedicated to Web Services calls and a generic filter chain for all other requests.

Please notice that the Web Services filter chain is defined before the generic filter chain because its path pattern is a subset of the generic filter chain pattern. Since the filter chains are examined in the order of their definition we are sure that Web Services requests will always be intercepted first and never be processed through the generic filter chain.

Let’s examine the generic filter chain in depth.

  1. securityContextPersistentFilter: this filter is used to store and retrieve the security context (user credentials, if any) between successive accesses to the application
  2. logoutFilter: this filter handles the logout. It should be placed at the beginning of the filter chain so a click on the logout link (or button) will not go through the rest of the chain
  3. authenticationProcessingFilter: this filter handles all the authentication process
  4. anonymousFilter: this filter handles anonymous login and creates an Authentication object in the HTTP session for later use
  5. exceptionTranslationFilter: this filter re-direct the user to an error page when Security exception is encountered
  6. filterSecurityInterceptor: this filter is manaing the access management

to be continued…


About DuyHai DOAN
Cassandra Technical Evangelist. LinkedIn profile : http://fr.linkedin.com/pub/duyhai-doan/2/224/848. Follow me on Twitter: @doanduyhai for latest updates on Cassandra

2 Responses to Spring Security part I : Configuration & Security Chain

  1. Pingback: Spring Security part II : SecurityContextPersistentFilter & LogoutFilter « Yet Another Java Blog

  2. Hi Duy Hai Doan,

    Can you explain more about in Spring Security Framework? I’ve tried to config as below but when i do a test, the result i get always is directing loginfail page, don’t why.

    Let me explain more about above queries: first i select username, user’s role and enabled from user’s table and the second query i select username, role from there tables (user, authority and role).


Leave a Reply to Thịnh Kều Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: