spring security原理图及其解释（2）
spring security原理图及其解释（二）
What does auto-config do behind the scenes?
In Spring Security 3, auto-config is used solely for automatic provisioning of following three authentication-related functions:
HTTP basic authentication
Form login authentication
Logout
The important interfaces related to authentication interact as shown in the following high-level diagram:
At a high level, you can see that there are three major components that are responsible for much of the heavy lifting:
o.s.s.core.Authentication is an interface with which you will interact with frequently, because it stores details of the user's identifier (for example, username), credentials (for example, password), and one or more authorities (o.s.s.core.GrantedAuthority) which the user has been given. A developer will commonly use the Authentication object to retrieve details about the authenticated user, or in a custom authentication implementation he/she will augment the Authentication object with additional application-dependent information.
The following methods are available on the Authentication interface:
Take note that AuthenticationProvider isn't directly used or referenced by the AuthenticationManager interface. However, Spring Security ships with only one concrete implementation (plus a subclass) of AuthenticationManager, o.s.s.authentication.ProviderManager, which uses one or more AuthenticationProvider implementations as described. As the use of AuthenticationProvider is so prevalent and well-integrated into the ProviderManager, it's important to review how it works in the most common scenarios with basic configuration.
Let's get into a little more detail and look specifically at the classes involved in the processing of a web-based username and password authentication request:
Let's take the abstract workflow seen in the high-level diagram and mentally bring it forward to work through this concrete implementation of form-based authentication. You can see that the UsernamePasswordAuthenticationFilter is responsible (through delegation from its abstract superclass) for creating the UsernamePasswordAuthenticationToken (an implementation of the Authentication interface), and partially populating it based on information in the HttpServletRequest. But where does it get the username and password from?
What does auto-config do behind the scenes?
In Spring Security 3, auto-config is used solely for automatic provisioning of following three authentication-related functions:
HTTP basic authentication
Form login authentication
Logout
The important interfaces related to authentication interact as shown in the following high-level diagram:
At a high level, you can see that there are three major components that are responsible for much of the heavy lifting:
o.s.s.core.Authentication is an interface with which you will interact with frequently, because it stores details of the user's identifier (for example, username), credentials (for example, password), and one or more authorities (o.s.s.core.GrantedAuthority) which the user has been given. A developer will commonly use the Authentication object to retrieve details about the authenticated user, or in a custom authentication implementation he/she will augment the Authentication object with additional application-dependent information.
The following methods are available on the Authentication interface:
Take note that AuthenticationProvider isn't directly used or referenced by the AuthenticationManager interface. However, Spring Security ships with only one concrete implementation (plus a subclass) of AuthenticationManager, o.s.s.authentication.ProviderManager, which uses one or more AuthenticationProvider implementations as described. As the use of AuthenticationProvider is so prevalent and well-integrated into the ProviderManager, it's important to review how it works in the most common scenarios with basic configuration.
Let's get into a little more detail and look specifically at the classes involved in the processing of a web-based username and password authentication request:
Let's take the abstract workflow seen in the high-level diagram and mentally bring it forward to work through this concrete implementation of form-based authentication. You can see that the UsernamePasswordAuthenticationFilter is responsible (through delegation from its abstract superclass) for creating the UsernamePasswordAuthenticationToken (an implementation of the Authentication interface), and partially populating it based on information in the HttpServletRequest. But where does it get the username and password from?