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-…

Upgrading Lead Microservice - Use MariaDB and Flyway with Spring Boot

So far I have been using an in-memory H2 database or Mockito for testing the lead microservice. To make the transition towards using the Spring Cloud Config server, I need to upgrade the micro-application to use MariaDB. I will be adding the configuration in the application.yml  the file which in the subsequent post will move over to the config server store. I will also be using Flyway to make it easy to maintain the database schema changes in future. I will use this post to introduce Flyway in the mix. Spring Boot also provides first class integration with Flyway. I am using Flyway as its really quick and easy to get started, minimal learning curve (no DSL) and I am comfortable with it having used it in the past.

Assumptions

MariaDB 10 is installedBasic familiarity with FlywayHeidi SQL client is installed.
Step 1 - Update build.gradle to include the MariaDB JDBC and Flyway dependencies.
Do not forget to do a Gradle refresh on your IDE (I am using STS 3.8.4 on Java 8)

Step 2 - Rename the…

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>