This article will discuss how users are authenticated and how security contexts are created when spring security features are added to web applications.
Environment:
spring boot Version: 1.5.4.RELEASE
1. The authentication process of a typical web application is as follows:
- User visits the website home page and clicks a link
- A request arrives at the server and the server sees that the user is accessing a protected resource
- Because the user has not been authenticated so far, the server sends back a response indicating that the user must authenticate first, either a response code or a direct redirect to the login page
- Depending on how authentication is implemented, the user may be redirected to the login page to wait for the user to enter form information such as username and password, or the browser may obtain the user's certificate in some way (a pop-up box in Basic authentication, the cookies mechanism, or certificate in the X509 authentication method)
- After the browser collects the authentication information, it will re-submit the request to the server. This request also varies according to the specific implementation. It can be an HTTP post submission with form information, or the HTTP header information contains authentication information details. simple request
- Next, the server will verify whether the authentication information submitted by the user is legal. If it is legal, the next step will be performed. If it is not legal, the user will usually be prompted to re-authenticate (re-execute the above two steps)
- The request that originally caused the user to authenticate will be retried. If the authentication information provided by the user has sufficient permissions to access the protected resource, the previous request will complete successfully, otherwise the user will receive a response code indicating insufficient permissions: 403
Most of the steps above are completed by a separate class in spring security. In the order of use, there are the following participants
- ExceptionTranslationFilter
- AuthenticationEntryPoint
- AuthenticationManager
2.ExceptionTranslationFilter
ExceptionTranslationFilter is a filter responsible for handling all exceptions thrown in spring security. These exceptions are usually thrown by the main authentication service provider, AbstractSecurityInterceptor. We will discuss this class further later. At this stage, we only need to know that it will generate authentication exceptions, and we don't need to care about how it performs authentication processing. ExceptionTranslationFilter will determine whether to return a 403 code representing rejection to the client based on the type of exception generated (when the user has been authenticated, but accesses a resource he does not have permission to access, the seventh step in the above steps), or Start an AuthenticationEntryPoint (when the user has not been authenticated, the third step of the above steps)
3.AuthenticationEntryPoint
AuthenticationEntryPoint is responsible for the third step in the above steps. In web applications with security control, there will be a default authentication strategy, and they will provide their own AuthenticationEntryPoint implementation to allow users to complete the authentication.
4. AuthenticationManager
Once the browser provides the authentication credential information (form information in the http post request or http header information), the server side needs a mechanism to collect this information, that is, perform the sixth step in the above steps, this process is in spring security is called the authentication mechanism. For example, the http header in the form-based login and Basic authentication mechanism, when the credential information is collected, the specific authentication mechanism will generate an Authentication object and provide it to the AuthenticationManager. If the credential information is valid later, the authentication mechanism will obtain a fully assembled Authentication object (including permission information) from the AuthenticationManager, store the Authentication object in the SecurityContextHolder, and re-execute the original request that triggered the authentication. If the credential information is invalid, the authentication The mechanism will require the user to re-authenticate.
5. Another core process - how to store the SecurityContext between requests
In a typical web application, the user authenticates once, and his subsequent operations will be marked by the corresponding session id, and does not need to be authenticated every time, the server is responsible for once This authentication information is cached during the session. In spring security, this function is implemented by SecurityContextPersistenceFilter. By default, it will store the authentication information in an attribute of httpSession. At the beginning of each http request, this filter will automatically take out the authentication context from the session. The information is stored in the SecurityContextHolder, and the authentication information is deleted from the SecurityContextHolder after the request is completed (for security reasons, ensure that the user who can perform the operation is indeed authenticated, and not the authentication information of others)
In some web applications (such as stateless restful web services), the session mechanism is not used, so each request will be authenticated, but we still need to add the SecurityContextPersistenceFilter to the filter chain, mainly to ensure that the SecurityContextHolder is completed after each request. will be cleared correctly.