Learn easily Spring Security filters in 3 steps?

Spring Security uses the filter chain to implement most of the security functions. In this post, we’re going to look at the Spring Security filter chain. We’ll learn how these filters work and how they run Spring Security internally.

Introduction to Spring Security filters

We drive Spring Security via the servlet filters in a web application. Servlet filters are used to block the request until it enters the physical resource (e.g. the Spring Controller). This is the way filters work in a web application:

1. The client sends a request for a resource (MVC controller). Application container Create Filter Chain to handle incoming requests.
2. Each HttpServletRequest passes through a filter chain based on the URI request route. (We can customize whether we run a filter chain for some request or URI related request).
3. Filters use the following rationale for much of the web framework.
   1. Update the HttpServletRequest or HttpServletResponse until you reach our Spring MVC controller.
   2. Can stop processing the request and send a response to the client. (e.g. Servlet that does not make requests to unique URIs).

Spring Security Filters Chains

For a web application that uses Spring Security, all incoming HttpServletRequest passes through the spring security filter chain until it hits the Spring MVC controller. Let’s build a Spring Security application before we go forward. This will help us develop a deeper understanding of the Spring FilterChain.
I use the spring boot auto configuration feature for my application, but you can create your application without the Spring Boot . Most of the principle is true for all of them. Build a basic controller for your application.

package com.onurdesk.controller;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class HelloController {

    @GetMapping("/Hello")
    public String hello() {
        return "Welcome Man!!";
    }
}

Add the following entry to the application.properties file and run the application and reach the following URL http:/localhost:8080/hello .

logging.level.org.springframework.security.web.FilterChainProxy=DEBUG

Look at the server console and you’ll see a similar output:

o.s.security.web.FilterChainProxy        : /hello at position 1 of 15 in additional filter chain; firing Filter: WebAsyncManagerIntegrationFilter'
o.s.security.web.FilterChainProxy        : /hello at position 2 of 15 in additional filter chain; firing Filter: 'SecurityContextPersistenceFilter'
o.s.security.web.FilterChainProxy        : /hello at position 3 of 15 in additional filter chain; firing Filter: 'HeaderWriterFilter'
o.s.security.web.FilterChainProxy        : /hello at position 4 of 15 in additional filter chain; firing Filter: 'CsrfFilter'
o.s.security.web.FilterChainProxy        : /hello at position 5 of 15 in additional filter chain; firing Filter: 'LogoutFilter'
o.s.security.web.FilterChainProxy        : /hello at position 6 of 15 in additional filter chain; firing Filter: 'UsernamePasswordAuthenticationFilter'
o.s.security.web.FilterChainProxy        : /hello at position 7 of 15 in additional filter chain; firing Filter: 'DefaultLoginPageGeneratingFilter'
o.s.security.web.FilterChainProxy        : /hello at position 8 of 15 in additional filter chain; firing Filter: 'DefaultLogoutPageGeneratingFilter'
o.s.security.web.FilterChainProxy        : /hello at position 9 of 15 in additional filter chain; firing Filter: 'BasicAuthenticationFilter'
o.s.security.web.FilterChainProxy        : /hello at position 10 of 15 in additional filter chain; firing Filter: 'RequestCacheAwareFilter'
o.s.security.web.FilterChainProxy        : /hello at position 11 of 15 in additional filter chain; firing Filter: 'SecurityContextHolderAwareRequestFilter'
o.s.security.web.FilterChainProxy        : /hello at position 12 of 15 in additional filter chain; firing Filter: 'AnonymousAuthenticationFilter'
o.s.security.web.FilterChainProxy        : /hello at position 13 of 15 in additional filter chain; firing Filter: 'SessionManagementFilter'
o.s.security.web.FilterChainProxy        : /hello at position 14 of 15 in additional filter chain; firing Filter: 'ExceptionTranslationFilter'
o.s.security.web.FilterChainProxy        : /hello at position 15 of 15 in additional filter chain; firing Filter: 'FilterSecurityInterceptor'

These filters are automatically configured for Spring Security and run on-incoming request. There are some important points that need to be remembered:

1. Filters run in a specific order (see the number). Filters can be modified depending on how we customize the modules.
2. Each incoming request will pass through all of these filters (15 in total in our case) in a particular order.Filters run in a specific order (see the number.

How Spring Security Filters Works

We’ve got the basics about Spring Security and it’s workflow. Spring Security requires servlet filters to execute much of its core logic, and it is very important that we understand the workflow. This will help us debug or configure security actions. Let’s take a close look at all the filters:

Above gives us a good picture of how the whole filter chain functions. Let’s highlight only a few important points

The DelegatingFilterProxy is a filter that serves as a bridge between the life cycle of the Servlet container and the Spring Framework Background. The Servlet Container does not have any knowledge about the Spring Framework Context, but the Spring Security requires security filters to perform the job.

DelegatingFilterProxy

⦁ Since DelegatingFilterProxy is a servlet filter, the application server registers it as a regular filter in the background.
⦁ As the name suggests, the DelegatingFilterProxy delegates the job to the spring bean to launch the security flow.

FilterChainProxy

This filter includes all the information of the various security filters accessible via the security filter chain. Let ‘s explain a few key points about the FilterChainProxy:

1. The FilterChainProxy will provide information about the various security filter chains and allocates the task to the chain depending on the URI mapping or using the RequestMatcher interface.
2. Not specifically executed, but began with the DelegatingFilterProxy filter

SecurityFilterChain

In our application, we may have several SecurityFilterChain configured.

1. Filter chain for the REST API starting with / api / v2/ * *.
2. Filter chain for internal communication / enterprise/ * *.
3. The Spring Security Filter Chain will contain several filters registered with the FilterChainProxy.
4. Each security filter can be designed in a special way.

Multiple Filter Chains:

Think of FilterChainProxy as a core module. The FilterChainProxy specifies which SecurityFilterChain should be used. Matches all incoming requests with the security filter chains and executes the first matched filter sequence.

Security Filters

OOTB Spring Security offers multiple filters for securities. It is usually not necessary to know every filter, just to bear in mind that it operates in a certain order or series. Let ‘s look at some of the essential filters.
⦁ UsernamePasswordAuthenticationFilter : Searches for the username and password of the request and attempts to authenticate if these parameters are included in the request.
⦁ SecurityContextPersistenceFilter : Populates the SecurityContextHolder with information that has been configured.
⦁ ConcurrentSessionFilter : Filter for managing concurrent sessions.
⦁ DefaultLoginPageGeneratingFilter : Generates a login page for you, if you specifically disable the feature.

Summary

We addressed spring security filters in this article. We’ve seen how the security filter chain works in a web application and how the various security filters operate. In the last section of the post, we spoke about the advantages of the architecture.