Skip to main content

Pause - lets look inside Spring Security

So far we have been quick to setup Spring Security and apply it in our application. But behind that minimal configuration and non-invasive behavior lot has been happening behind the scenes.
It is time to uncover the activities under hood, draw some diagrams to understand the framework and move ahead in style. I will not draw out all the balls from the magic box now. Instead will slowly take out one ball at a time to make it slow and easy to comprehend and assimilate.

Let us go back to the web.xml configuration. You will see that we have configured a DelegatingFilterProxy. This filter is named 'springSecurityFilterChain'. The delegating filter proxy looks for a bean named 'springSecurityFilterChain' in the root Spring web application context. So note that this name is kind of a reserved bean name and should not be used elsewhere. The delegating filter proxy as the name suggests delegates the entire security processing then to the beans declared in the Spring web application context/ or security context. Now the question in your mind is that you never declared a bean with name - 'springSecurityFilterChain' , then from where on earth did the delegating filter proxy get it and the framework started running? Well the 'springSecurityFilterChain' bean is created by the declaration <http>....</http>

There is a lot to learn and understand with this namespace configuration - <http&gt. So it needs a be enjoyed slowly like a good whisky.

You must have already understood that Spring Security is based on servlet filters. This is what the official documentation says - "Spring Security's web infrastructure is based entirely on standard servlet filters. It doesn't use servlets or any other servlet-based frameworks (such as Spring MVC) internally, so it has no strong links to any particular web technology. It deals in HttpServletRequests and HttpServletResponses and doesn't care whether the requests come from a browser, a web service client, an HttpInvoker or an AJAX application. Spring Security maintains a filter chain internally where each of the filters has a particular responsibility and filters are added or removed from the configuration depending on which services are required. The ordering of the filters is important as there are dependencies between them. "

Just to extract the keywords - irrespective of the source of http request the intercepting filter (configured as a delegating filter proxy in web.xml) hands over the actual security processing to a filter chain configured internally or Spring web application context. The request passes through each of the internal filters and is processed depending on what are the security requirements of the application or what customization has been done. Note you can very well introduce your own filter.Also note that the order of the filter in the filter chain is very important and there may be dependencies between filters in the chain. A filter coming later in the chain may depend on some data produced by filter coming earlier in the chain. I will dig deep into all these and also take indepth look into different filters that are available out of the box and also try to show the use of a custom filter in the chain.

Since we used the new namespace based configuration, the required filters are automatically configured and no bean needs to be explicitly configured. But sometimes fine grained control is required (and these may not be supported in namespace based configuration). In this case it is very well possible to get full control over the filter chain and the filters.

Now I leave you with a big picture of Spring security. In my next post I will to uncover more details about Spring security and its filters. I will blow out that yellow box more in the next post.

Comments

Popular posts from this blog

Why do you need Spring Cloud Config server?

Last month I wrote a primer on concepts around 12 factor app. Before getting into the details of the Spring Cloud Config Server, I must refresh on the principle #3 from the list presented in that post.

3 – ConfigurationStore config in the environments
Configuration information must be separate from the source code. This may seem so obvious, but often we are guilty of leaving critical configuration parameters in the scattered in the code. Instead, applications should have environment specific configuration files. The sensitive information like database password or API key should be stored in these environment configuration files in encrypted format.
 The key takeaways from this postulate for a cloud-native microservices application are:
Do not store configuration as part of the deployable unit (in the case of lead microservice - inside the jar or war if you are still deploying war like the good old days). Instead, store it in an external location and make it easily accessible during run-…

Changing the root web application in Tomcat 6

These days I am very busy developing a large and complex web application, which is nearing its first release. This web based product runs on Tomcat 6 and will be deployed on http://www.mydomain.com
But if I deploy my web application on Tomcat 6, I need to specify the context root. Well this is no good, why will the users of this website be willing to remember the context root. What if the context root changes. In other words the users would not be interest in typing the following - http://www.mydomain.com/myappcontext to visit this site.
Hence it is necessary that I change the default / root web application of Tomcat and point it to my application. I wanted to try and test this on localhost first. As always I Googled and found a number of posts and none seem to work. I also read the documentation it was helpful in understanding the concepts but was not effective as I could not get it working. Finally after few hours of trial and error one of my colleague Joyeeta Majumdar found the so…

Part 3 - Integrating Tiles, Thymeleaf and Spring MVC 3

In this post I will demonstrate how to integrate Apache Tiles with Thymeleaf. This is very simple. The first step is to include the tiles and thymeleaf-tiles extension dependencies. I will include them in the pom.xml. Note we wil lbe using Tiles 2.2.2Listing 1 - parent/pom.xml --- thymeleaf-tiles and tiles dependencies <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
<!-- Tiles -->
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->

<dependency>
<groupId>org.apache.tiles</groupId>
<artifactId>tiles-core</artifactId>
<version>${tiles.version}</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.apache.tiles</groupId>
<artifactId>tiles-template</artifactId>
<version>${tiles.version}</version>
<scope>compile</scope>