First, the recipe encourages developers to override the default URL /login, the default login processing for Spring Security 4.x. To avoid conflicts with the previous configuration, we must declare a new URL through the http.formLogin().loginProcessingUrl() method, given that this URL is non-existent and non-controller-based. This new processing URL must be executed using a POST request; otherwise, a HTTP status 405 will be thrown.
Second, the recipe highlights the customization of the whole authentication and authorization process. The Spring Security architecture lies mainly with who will use the MVC application and what access levels each user will have. To depend on the default framework mechanism is not acceptable, especially in cases where the security requirement becomes complex and unconditional. In order for the module to comply with the security requirement, it is recommended to implement a customized version of the AuthenticationManager. This class only requires one method to be overridden, and that is authenticate(), which returns an Authentication object once the access is allowed, throws AuthenticationException if the access is not allowed, or returns a null object for certain conditions.
AuthenticationManager delegates the authentication process to a chain of providers, which needs to be implemented to avoid a fat custom AuthenticationManager. To inject the custom manager and its providers, WebSecurityConfigurerAdapter's authenticationManager() must be overridden to establish the new authentication chain comprised of the list of providers and the custom parent authentication manager.
This recipe is designed so that the first provider to be executed during /login_process is the AppAdminProvider. This provider will redirect the user to /deptform.html once the user credentials are considered valid; otherwise, the next provider, AppHRProvider, will be next to run its authenticate() method. An exception must be thrown from AppHRProvider to trigger the execution of AppAuthenticationManager, which gives us the conclusion that the last to authenticate() is the parent authentication manager. Returning null values will also trigger the authentication chain. The whole chaining process is indicated in the following diagram:
The only problem with designing authentication chaining is when all the providers and managers do not cooperate to achieve one security goal. The tasks of each node in the chain must be mutually-exclusive and must not create inconsistencies and conflicts that can make the login/logout mechanism out of control.
In this recipe, every AuthenticationException thrown by each provider or the parent manager leads to the execution of the failureUrl(). This exception is not a normal runtime exception and can only be caught inside the chain. Some implementations of AuthenticationException that can be used to classify login credential-related exceptions are AuthenticationServiceException, BadCredentialsException, SessionAuthenticationException, and UsernameNotFoundException.
Customizing the Spring Security authentication does not only involve the implementation of the authentication chain but also the building of user credentials and their roles. This recipe eliminated the creation of an in-memory user databank but instead created an internal and programmatical way of building user credentials through the use of providers and authentication managers.