This article mainly describes the implementation of authentication in spring security. Currently, spring security supports three authentication methods based on spring aop, filter, and aspectj, providing access control for method calls, web requests, and business objects, respectively. The soundness in spring security is mainly completed by the AccessDecisionManager class, which has a decide method that accepts an Authentication object representing the authenticator information, a security object, and a list of security attributes associated with this object. (eg a list of roles representing the required permissions)
1. AOP notifications
There are four notification types in spring aop: before, after, throws and around. The around notification can choose whether to execute the method call, whether to modify the return result, or whether to throw an exception. Spring security is to use around to protect method calls, and use filter to protect web requests.
In most applications, we only need to use spring aop to protect the method calls of the service layer, because this is where our main business is implemented. If we also need to protect the business object directly, we need to consider using AspectJ to complete it, and AspectJ can also implement the protection of method calls. In the actual application, we can choose according to our needs, or we can choose two or three combinations to use. The current mainstream practice is to use filter for web request authentication, combined with spring aop to authenticate and protect the method of the service layer.
2. Security objects and AbstractSecurityInterceptor
In spring security, security objects refer to objects that require security measures. The most common examples are method calls and web requests.
Each security object type has its corresponding interceptor class that inherits AbstractSecurityInterceptor. The most important thing is that when the AbstractSecurityInterceptor is called, if the user has been authenticated, the SecurityContextHolder will definitely contain a valid Authentication object.
The general execution process of the AbstractSecurityInterceptor interceptor is as follows:
- a. Find configuration attributes related to the current request - configuration attributes (such as a list of permissions)
- b. Pass the Authentication object, security object and configuration properties to the decide method of AccessDecisionManager
- c. Optionally change the incoming Authentication object
- d. Release the call to the secure object (assuming the current user has access rights)
- e. If AfterInvocationManager is configured, continue to call AfterInvocationManager when the decide method ends. If an exception is thrown inside the decide method, it will not be called.
3. Configuration attributes: Configuration Attributes
configuration attributes can be simply considered as strings with special meaning to AbstractSecurityInterceptor, which are represented by the ConfigAttribute class in spring security. According to the specific implementation of AccessDecisionManager, this attribute can be a simple role name, or it can contain a specific meaning. There is a securityMetadataSource property in AbstractSecurityInterceptor, which is used to find the configuration properties corresponding to the currently accessed object. The SecurityMetadataSource properties of the specific implementation classes of AbstractSecurityInterceptor are also different. In FilterSecurityInterceptor, FilterInvocationSecurityMetadataSource is used to represent these security properties, and MethodSecurityInterceptor is represented by MethodSecurityMetadataSource. The setting methods are also different. FilterInvocationSecurityMetadataSource is set through uris, and MethodSecurityMetadataSource is set through annotations on the method.
antMatchers("/admin/**").hasRole("ADMIN")
It means that the configuration attribute corresponding to url: /admin/** is ADMIN. In actual operation, this means that any user who has the authority of the ADMIN role can access the url /admin/**. Therefore, strictly speaking, configuration properties are just some common properties, and how these properties are resolved depends on the implementation class of AccessDecisionManager. In subsequent chapters, we will continue to discuss how AccessDecisionManager is implemented.