Overview about request processing in Spring Security

To be able to make authentication and authorization for the requests to the web application, Spring Security must act as an interceptor of these applications. It will intercept and process the requests before those requests are actually processed by the application and return results. In this tutorial, we will find out that before processing the request by application, what does Spring Security do!

First, for you to easily imagine, I will create a new Spring MVC application that supports Spring Security as an example:

Overview about request processing in Spring Security

with Spring Security dependencies as follows:

The security.xml file has the following content:

This security file defines the user “khanh” with the role ROLE_USER to have access to the application with the context path “/”.

Of course, you must also configure the web.xml file to add the Spring Security configuration file.

The first thing I want to say about the request handling process in Spring Security is that we have to talk about the DelegatingFilterProxy class declared in the web.xml file of the application. This is the Java Servlet’s javax.servlet.Filter interface, which acts as an interceptor, filtering all requests to Java web applications. This class is implemented to be managed by the Spring container.

If you have worked with the Java Servlet Filter, you will know that the doFilter() method in this javax.servlet.Filter interface will help us to add code to handle the interceptor, the DelegatingFilterProxy class also uses the doFilter() method to do this.

If you look at the code of the DelegatingFilterProxy class, you will see, actually in the doFilter() method of the DelegatingFilterProxy class, it does nothing. It only delegates filtering through another class, org.springframework.security.web.FilterChainProxy. The FilterChainProxy class also implements the javax.servlet.Filter interface with the doFilter() method. Specifically, what does the FilterChainProxy class do in doFilter() method, similar to the tutorial in Overview about request processing in Spring MVC, I will also modify the application project’s log4j.xml file to log out all the information that Spring Security performs when it authenticates and authorizes!

I will change the level of the loggers for the Spring framework from info to debug in the “3rdparty Loggers” section and root logger the priority from warn to debug. I also declared a logger for the org.springframework.security package of Spring Security.

At this time, the content of log4j.xml file will be as follows:

Now, if you run the application and request to http://localhost:8080, check the console, you will see the following log lines:

Looking at the above loglines, you can see, with our config in the security.xml file, when calling the request to the home page of the application, there are 15 Filter classes called by the FilterChainProxy class to Spring Security that can carry out its responsibilities. Each filter has its own function and task, and if you look at the code of the UsernamePasswordAuthenticationFilter class and the BasicAuthenticationFilter class, you will see that these two classes will take care of the authentication handling in Spring Security. UsernamePasswordAuthenticationFilter will take care of authentication when the user calls the POST request “/login” and BasicAuthenticationFilter will take care of authentication with user and password information passed on the request header. Both of these filters call the authenticate() method of the AuthenticationManager interface to perform authentication.

In addition to the AuthenticationManager interface, the common implementation of this interface is the ProviderManager class. The ProviderManager class will call a list of AuthenticationProvider which we declared in Spring Security’s configuration file, security.xml:

Overview about request processing in Spring Security

to check the support of these AuthenticationProvider and perform authentication.

Overview about request processing in Spring Security

By default, the DaoAuthenticationProvider class will take care of authentication. It will use the UserDetailsService class to get the user information that we declared in the security.xml configuration file to do this.

Details of the authentication, you can read more code! I can overview the authentication in Spring Security as follows:

Overview about request processing in Spring Security



To see how authorization works, try clearing the stack trace of the IDE and logging in with the username “Khanh” and the password “123456”.

You’ll see the following log lines:

If you look closely at the logs above, you will see the text “Authorization successful” and the AffirmativeBased class is the class that implements this authorization!

The AffirmativeBased class implements the AccessDecisionManager interface, this is the main interface for authorization in Spring Security!

AccessDecisionManager inteface has 3 implementations and the implementation that we often use is the AffirmativeBased class.

Overview about request processing in Spring Security

If you look at the code of the AffirmativeBased class, you will see in the decide() method of this class, it is looping a list of AccessDecisionVoter to determine whether the user has the right to see the resource they are requesting or not?

Overview about request processing in Spring Security

Read more code, guys! 🙂

5/5 - (1 vote)

Add Comment