Spring Security Certification Process

 

Directory

1.1 Certification process

1.2 Certification process for Web applications

1.2.1 Exceptiontranslationfilter

1.2.2 Sharing securitycontext between request

1.1 Certification process

1, the user login with the user name and password.

2. Spring security encapsulates the acquired username and password into a usernamepasswordauthenticationtoken that implements the authentication interface.

3, the above-generated token object is passed to AuthenticationManager for login authentication.

4, AuthenticationManager authentication will return a authentication object that encapsulates information such as user rights.

5, by calling Securitycontextholder.getcontext (). Setauthentication (...) Assigns the authentication object returned by AuthenticationManager to the current securitycontext.

The above description is the Spring security certification process. Once the authentication is successful, the user can continue to access other protected resources, but will use the authentication object stored in SecurityContext to authenticate the permissions.

1.2 Certification process for Web applications

If the user directly accesses the login page, then the authentication process is basically the same as described in the previous section, except that when the authentication is complete, it jumps to the specified success page, which defaults to the root path of the app. If a user accesses a protected resource directly, the authentication process is as follows:

1, guide users to log in, usually redirect to a form based on the form to log on the page, depending on the configuration.

2, the user entered the user name and password request authentication, the background will be as described in the previous section to obtain the user name and password encapsulated into a Usernamepasswordauthenticationtoken object, Then pass it on to the AuthenticationManager for certification.

3, if the authentication failure will continue to perform step 1, if the authentication is successful will save the returned authentication to SecurityContext, and then by default will redirect the user to the previously visited page.

4, the user login authentication after the successful re-access to the previously protected resources will be authenticated to the user, if there is no corresponding access rights, will return 403 error code.

There will be many different classes involved in the above steps, but the main participants are exceptiontranslationfilter.

1.2.1 Exceptiontranslationfilter

Exceptiontranslationfilter is used to handle the authenticationexception and accessdeniedexception thrown from Abstractsecurityinterceptor. Abstractsecurityinterceptor is the spring security used to intercept requests for permission authentication, which has two specific subclasses, Intercepts the Methodsecurityinterceptor of the method call and intercepts the filtersecurityinterceptor of the URL request. When Exceptiontranslationfilter captures Authenticationexception, it calls Authenticationentrypoint to boot the user to log on. If the capture is accessdeniedexception, but the user has not yet passed authentication, call Authenticationentrypoint to boot the user for login authentication, otherwise a 403 error code indicating that no corresponding permission is present will be returned.

1.2.2 Sharing securitycontext between request

Perhaps you have already had such a doubt, since SecurityContext is stored in the threadlocal, And in each authorization is obtained from threadlocal in the corresponding authentication in the SecurityContext to have the permissions, and different request is different threads, Why is it possible to get the securitycontext of the current user from threadlocal every time? This is achieved through Securitycontextpersistentfilter in the Web application, which, by default, gets SecurityContext from the session at the beginning of each request. Then set it to Securitycontextholder, and after the request is over, the SecurityContext held by Securitycontextholder will be saved in the session, and clear the SecurityContext held by Securitycontextholder. So when we first visited the system, Securitycontextholder's securitycontext must be empty, and after our successful login, Securitycontextholder hold the SecurityContext is not empty, and contains a successful authentication object, after the request is over we will be securitycontext in the session, Wait until the next request to get the SecurityContext from the session and give it to Securitycontextholder, Since Securitycontextholder already has a certified authentication object, it is no longer necessary to login for the next visit.

(Note: This article is written based on spring Security3.1.6)

Spring Security Certification Process