Spring’s DelegatingFilterProxy serves as a proxy for a Servlet Filter. It delegates to a Spring-managed bean that implements the Filter interface.
I had never given much thought to how Spring Security integrates with web.xml until I had to diagnose an issue involving the DelegatingFilterProxy and my Spring Security configuration.
I knew the starting point is the springSecurityFilterChain which uses the DelegatingFilterProxy, and this would instantiate the Spring Security filters according to my Spring configuration:
But what next?
A look at the Javadoc for DelegatingFilterProxy states that:
Proxy for a standard Servlet Filter, delegating to a Spring-managed bean that implements the Filter interface
It further states that the filter-name corresponds to a bean in the Spring application context.
So in terms of Spring Security, the DelegatingFilterProxy will look through the Spring Application Context for a bean “springSecurityFilterChain”. The only requirement for Delegated beans is that they must implement javax.servlet. Filter.
The springSecurityFilterChain is initialised in your spring configuration by, which will be passed to your DispatcherServlet:
We can see this in action when we include code to add remove filters in Spring Security:
You can also see a list of filters created when you up spring security logging
Spring Security configuration for Spring Boot is simply a matter of adding a reference to “spring-boot-starter-security” to Gradle or Maven. We can then fine tune the security configurations through @EnableWebSecurity and overriding the configure method of a class extending WebSecurityConfigurerAdapter.
If we dig around under the hood we find that the DelegatingFilterProxy is still used. With the “springSecurityFilterChain” instantiated in SecurityFilterAutoConfiguration, which populates the DelegatingFilterProxyRegistrationBean with “springSecurityFilterChain” (AbstractSecurityWebApplicationInitializer. DEFAULT_FILTER_NAME) :
