Now, let's start the application with the mvn spring-boot:run command. Once the application starts, you can see the following information in the output:

Mapping filter: 'springSecurityFilterChain' to: [/*]

Because it is mapped to a wildcard (/*), the Spring Security filter chain will handle all of the requests the application receives. 

Another log that you will see in the output is the following: 

o.s.s.web.DefaultSecurityFilterChain     : Creating filter chain: org.springframework.security.web.util.matcher.AnyRequestMatcher@1, [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@3c2b5b0a, org.springframework.security.web.context.SecurityContextPersistenceFilter@240d2b4d, org.springframework.security.web.header.HeaderWriterFilter@711e7156, org.springframework.security.web.authentication.logout.LogoutFilter@d7be699, org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter@77b0917e, org.springframework.security.web.savedrequest.RequestCacheAwareFilter@2f67b8d8, org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@369a4ddd, org.springframework.security.web.authentication.AnonymousAuthenticationFilter@5f6eca45, org.springframework.security.web.session.SessionManagementFilter@98d744b, org.springframework.security.web.access.ExceptionTranslationFilter@7fc7231d, org.springframework.security.web.access.intercept.FilterSecurityInterceptor@5604e1a5]

As you can see, with our configuration of HttpSecurity, Spring Security created these filters for us. Let's take a look at these filters in a different view. The following figure shows a request comes in from the left side and gets processed by each of these filters in order, and the interaction some of these filters have with SecurityContext:

Among these filters, the most important ones are SecurityContextPersistenceFilter, UsernamePasswordAuthenticationFilter, ExceptionTranslationFilter, and FilterSecurityInterceptor. Based on the version of Spring Security you're using, the filters created in this filter chain might be different from the ones we listed. However, these four filters have a very similar responsibility and will still be present in order to make it work. Now, let's go through these Spring Security filters one by one to see what they do:

• WebAsyncManagerIntegrationFilter: This filter provides integration between SecurityContext and Spring Web's WebAsyncManager, which is the central class for managing asynchronous request processing.
• SecurityContextPersistenceFilter: The next filter that the request reaches is SecurityContextPersistenceFilter, which is one of the filters that must be present in the chain in order to have Spring Security function normally. As you can see in the diagram, when the request comes in, this filter will set up SecurityContext by loading it from SecurityContextRepository, which is by default implemented based on HttpSession. Once SecurityContext is loaded, the filter will put it inside SecurityContextHolder so that, after this filter, it can be accessed through SecurityContextHolder.getContext(). On the other hand, when the request goes out through this filter, SecurityContext will be updated back to SecurityContextRepository so that any changes to SecurityContext will be persisted between requests. The filter will also clear SecurityContextHolder to avoid leaking security context to other requests that might not be from the same user.
• HeaderWriterFilter: This filter adds headers to the response of the current request. It is useful to add certain headers, which enable browser protection, for example, X-Frame-Options, X-XSS-Protection, and X-Content-Type-Options.
• LogoutFilter: As its name states, this filter will log out a user who has been authenticated. By default, the logout processing URL is /logout. So, it will only execute the logout procedure when a request is sent to that path. The logout processing URL is configurable through HttpSecurity, which is the one we use in our SecurityConfiguration.
• UsernamePasswordAuthenticationFilter: The UsernamePasswordAuthenticationFilter is where the authentication starts. This filter holds a reference to an instance of ProviderManager, which is an implementation of the AuthenticationManager interface. ProviderManager holds a list of AuthenticationProvider, which are used to perform the actual authentication. The most commonly used authentication provider is DaoAuthenticationProvider, which uses UserDetailsService to load UserDetails of the same username from the database. Then DaoAuthenticationProvider checks if the provided password in the request matches the one in UserDetails. If it matches, the authentication passes; otherwise, it fails. When the authentication succeeds, UsernamePasswordAuthenticationFilter will update SecurityContext, and the user will be regarded as authenticated. AuthenticationSuccessHandler will take control of the request. By default, a redirection to the default success URL will occur. When the authentication fails, SecurityContextHolder will be cleared and AuthenticationFailureHandler will take control of the request. By default, the user will be redirected to the /login?failed page. UsernamePasswordAuthenticationFilter won't trigger the authentication process for any request. It will only do it for a request that is sent to the /login path using the HTTP POST method.
• RequestCacheAwareFilter: This filter restores the previous cached request, which is usually saved by ExceptionTranslationFilter when a request fails. For example, when an authenticated request is sent to access a protected resource, Spring Security will block that request and send the user to the login page. After a successful authentication, the user will be redirected back to the protected resource. Spring Security knows where the user should go after authentication by checking the cached request.
• SecurityContextHolderAwareRequestFilter: This filter is responsible for the request with a wrapper that implements servlet API security methods, such as the following:

• HttpServletRequest.authenticate(HttpServletResponse)
• HttpServletRequest.login(String, String)
• HttpServletRequest.logout()

We will not use these APIs in TaskAgile.

• AnonymousAuthenticationFilter: What this filter does is update SecurityContext with AnonymousAuthenticationToken when it finds that no Authentication is present in SecurityContext. It doesn't really perform authentication for anonymous users. It is more like putting a placeholder authentication in SecurityContext to make it clear that the request is sent from an anonymous user.
• SessionManagementFilter: This filter is responsible for activating session-fixation protection and controlling the concurrent sessions, which requires ConcurrentSessionFilter to be in the chain. To turn on concurrent session management, we can use the following setting provided by HttpSecurity. By default, there is no limitation:

http.sessionManagement().maximumSessions(n);

• ExceptionTranslationFilter: This is the second to last filter in the chain. As its name states, this filter is responsible for translating Spring Security exceptions. When there is AuthenticationException caught, the filter will launch the authentication endpoint. If there is AccessDeniedException caught and the user is anonymous, the filter will also launch the authentication endpoint; when the user is not anonymous, AccessDeniedHandler will by default send an HTTP 403 response.
• FilterSecurityInterceptor: The last filter in the chain is FilterSecurityInterceptor, which has a reference to AccessDecisionManager. The filter retrieves SecurityContext and then delegates to AccessDecisionManager to decide whether the request is allowed or not, and raise exceptions when the request is denied. If the request is allowed, it will reach the corresponding Controller. The decision that AccessDecisionManager makes is based on votes. The decision made here is at the request level. It means that Spring Security checks the path of the request against the configuration on HttpSecurity and sees if the granted authorities found inside SecurityContext are sufficient to permit access.