In the previous chapters, we have described some components of spring security. Next, we will focus on two other important authentication-related interfaces and their implementation classes: AuthenticationManager, UserDetailsService.
1.AuthenticationManager, ProviderManager and AuthenticationProvider
AuthenticationManager is the core interface of authentication. There is only one method authenticate, which passes in an Authentication object to be authenticated, and returns a fully assembled Authentication with permission information. So how does it perform in practice, and what if we want to check multiple authentication databases, or if we want to use two or more authentication methods such as database➕LDAP combined?
The default implementer of AuthenticationManager in Spring Security is ProviderManager. This class itself does not perform authentication operations, but delegates the authentication process to the configured AuthenticationProvider list. The AuthenticationProviders in the list will take turns to try to complete the authentication. Each specific AuthenticationProvider either throws an exception when trying to authenticate, or completes the authentication and returns an assembled Authentication object (in the ProviderManager, it will catch the authentication exception and continue to try the next provider's authentication). The most common authentication method is to call loadUserByUsername of UserDetailsService to obtain a UserDetails object according to the username in the incoming Authentication. If necessary, the user's permission information will then be obtained and packaged into a specific UserDetails object and returned to the specific UserDetails object. In the AuthenticationProvider class, and then in the specific AuthenticationProvider implementation class, it will determine whether the password entered by the user is the same as the password in the UserDetails returned to us by UserDetailsService (if required, the PasswordEncoder will be used here to encrypt the password entered by the user and then communicate with the user. The password comparison of UserDetails, about PasswordEncoder will be described later), which is also the authentication process of DaoAuthenticationProvider, the most commonly used provider. The obtained UserDetails and the permission information it contains will be used to assemble the Authentication and stored in the SecurityContext (done in the AbstractSecurityInterceptor class we discussed in the previous section).
When using the java config configuration form of spring boot, after we introduce the @EnableWebSecurity annotation, the system will automatically register the default implementation of ProviderManager for us. The specific logic can refer to [urlhttp://fengyilin.iteye.com/admin/blogs/2410779]spring -security (2) java config loading mechanism[/url], if you want to add our custom provider, you can use AuthenticationManagerBuilder
@Autowired
public void auth(AuthenticationManagerBuilder auth) throws Exception {
auth.authenticationProvider(new MyCustomProvider());
}
In addition, AuthenticationManagerBuilder also provides us with a method of appending common providers
- inMemoryAuthentication() provides memory-based authentication
- jdbcAuthentication() provides authentication based on relational database
- userDetailsService(T userDetailsService) provides authentication based on relational database and uses our custom UserDetailsService
- ldapAuthentication() provides LDAP-based authentication
If all providers do not support authentication for the current security object, the ProviderManager will throw a ProviderNotFoundException.
In some authentication mechanisms, such as the filter-UsernamePasswordAuthenticationFilter based on web form submission, a ProviderManager will be injected, and the authentication method of the ProviderManager will be called when authentication is required. Sometimes the providers we need to use can be replaced with each other. For example, DaoAuthenticationProvider and LdapAuthenticationProvider are compatible with all authentication methods that provide username/password, so they can be used for both form-based login authentication and HTTP Basic authentication. However, there are some authentication mechanisms that can only be parsed by a specific provider, such as JA-SIG CAS, which is verified through a service ticket, so only CasAuthenticationProvider can be used to complete the authentication.
2. After the authentication is successful, the certificate information is erased
By default, ProviderManager will try to erase sensitive credential information (such as user password, service ticket) in Authentication. This poses a small problem in the case of cached users, such as in stateless web service applications, where authentication is required every time. At this time, if the credential information is removed, the authentication cannot be re-completed by using the cache award, so in this case we have to add our own processing. One solution is to implement the class in our cache or in the custom before returning to the ProviderManager. First copy the Authentication object in the AuthenticationProvider class, or set eraseCredentialsAfterAuthentication in ProviderManager to false (default true);
@Autowired
public void auth(AuthenticationManagerBuilder auth) throws Exception {
auth.eraseCredentials(false);
}
3.DaoAuthenticationProvider
DaoAuthenticationProvider is the simplest AuthenticationProvider implementation class and the earliest authentication method supported by spring framewor. It uses an implementation class of UserDetailsService (through the jdbcAuthentication() method of AuthenticationManagerBuilder, we will provide DaoAuthenticationProvider with a JdbcUserDetailsManager that implements UserDetailsService). DaoAuthenticationProvider also has an optional PasswordEncoder property, which is used to encode and decode the password in UserDetails obtained by UserDetailsService. We will discuss the PasswordEncoder class separately later.