Simple web application with Spring Security: Part 14

In the last page on the series, we were following a http request through the current configuration of spring security for our simple web application. The request had reached the FilterChainProxy was about to be filtered through each of the filters.

These filters have been setup by default by spring security based on the configuration we have used as mentioned in the previous page of the series.


The HttpSessionContextIntegrationFilter as is says is its javadoc is responsible for populating spring securities security context with any information that exists in the current HttpSession. For these reasons it must be executed ahead of any authentication processing that may take place; hence its order in the FilterChainOrder.

After ensuring that the state of the security context is up to date with any state in the HttpSession the request is next filtered using the AuthenticationProcessingFilter.


The AuthenticationProcessingFilter is responsible for authenticating login requests if necessary. In this case the request is a simple get request to view the login page so it will not attempt authentication but instead carry on to the next filter.


The SecurityContextHolderAwareRequestFilter is responsible for modifying the request to be one of a request wrapper type e.g. SavedRequestAwareWrapper. This is to store some useful information in a more convenient way so spring security framework can work with the request.

In general its not something that we would need to modify for the vast majority of applications.


Next the request is filtered by the ExceptionTranslationFilter. This filter is responsible for determining how to handle any AccessDeniedException or AuthenticationException that may get thrown by any of the filters executed after it in the filter chain.

Lastly the request (for our configuration) reaches the FilterSecurityInterceptor.


The FilterSecurityInterceptor is responsible implementing security interception for secure objects using a filter approach.

After passing through all these filters, we get our response back which mean we get to see the login.jsp page.


In Spring Security 2.0.x, there most likely won’t be the need to explicitly configure a FilterChainProxy bean in your application context unless you need very fine control over the filter chain contents. A good number of cases should be handled by the default namespace configuration approach.

One of the problems of using a framework like spring security is that sometimes, it can become too easy to just follow some examples and configure it to do what you want without truly understanding how the mechanics of it really work. Somehow due the configuration, some magic happens in the background and you get your desired functionality.

Spring Security offers loads of excellent out of the box features relating to security that should without doubt improve quality and productivity for the vast majority of applications. For those that have ‘corner-case’ requirements, Spring Security is allows for plenty of ways to extend its capabilities. Its worth investing some time in familiarizing yourself with the framework and getting to know how it works.

Coming up in the series

I will continue adding back in the security features of the application at the web/presentation level while continuing to look deeply at the internals. From there we will explore more finer grained approaches to security such as method-level and domain-instance level security.


Leave a Reply

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

You are commenting using your 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: