The main idea is to create a customized filter chain that will manage the whole access to the application. In this recipe, the authentication procedure for valid users and the anonymous account has been overridden to accommodate some details not inherent to the framework. For instance, the framework recognizes anonymous access, but it does not provide a set of rules for it. The recipe creates an anonymous guest account whose access to the application will be redirected by org.springframework.security.web.AuthenticationEntryPoint to its own content page, which is /deptanon.html. This conveys that the anonymous access is restricted from accessing the /deptform.html, which is only for the authenticated users. The assessment of any anonymous access is the major responsibility of AnonymousAuthenticationFilter, with the intervention also of the UsernamePasswordAuthenticationFilter. The former checks first if the authentication request is a guest or is bearing an anonymous access key before the authentication process creates the AnonymousAuthenticationToken. Otherwise, it throws null for the latter to create a UsernamePassswordAuthenticationToken, indicating that the access is not anonymous and must undergo the authentication process by the manager and its providers. Thus, its configuration will not work without the injection of the custom AuthenticationManager and AuthenticationProvider provided in the previous recipe:

The validation of whether the Authentication is anonymous or not is the ultimate job of org.springframework.security.authentication.AuthenticationTrustResolver, which completes the puzzle of why the filters and the authentication providers communicate each other. The AuthenticationTrustResolver evaluates all the Authentication objects thrown by filters and providers into the container at runtime. It is also the exact object that helps the AuthenticationEntryPoint determine when to redirect a user to an anonymous page.

Security filters must be implemented properly so as not to contradict each other or to interfere with the results of some filter methods. To avoid unexpected results, HttpSecurity has methods (custom filters) that can set the order of filter execution, and these are:

• addFilter: This adds a custom Spring Security filter anywhere in the filter chain
• addFilterBefore: This adds a custom filter before an existing specified filter class in the chain
• addFilterAfter: This adds a custom filter after an existing specified filter class in the chain
• addFilterAt: This adds a custom filter at the location of an existing specified filter class in the chain

On the other hand, the security chain will not be complete without the existence of the custom handlers, such as CustomSuccessHandler, CustomFailureHandler, and CustomLogoutHandler. Both CustomSucessHandler and CustomFailureHandler are triggered to manage the different page redirections during the login processing while CustomLogoutHandler provides different logout redirections once the /logout process is executed. The framework's DefaultRedirectStrategy is used to manage the redirection of each handler without specifying the context paths.

Because of Spring Security's flexibility, its filter chain may contain several custom chains as needed by the application, and some of the widely used ones are LogoutFilter, ConcurrentSessionFilter, X509AuthenticationFilter, CasAuthenticationFilter, and JaasApiIntegrationFilter.

These security filters can store specific user details and information to SecurityContext and can be accessed by any of the components of the application. This object can only be accessed through org.springframework.security.core.context.SecurityContextHolder.