Spring Security in-depth discussion

Spring security is a mature framework for identity authentication and access control. It is mainly used for web URL access. Of course, it can also be used for more fine-grained access control (method control) but the former is more universal, and this article discusses the former.
Quick Start, a simple example

Step 1: Add spring Security proxy filter in Web. xml.

    <filter>        <filter-name>springSecurityFilterChain</filter-name>        <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>    </filter>    <filter-mapping>        <filter-name>springSecurityFilterChain</filter-name>        <url-pattern>/*</url-pattern>    </filter-mapping>

Step2: spring-security-context.xml

    <beans:beans xmlns="http://www.springframework.org/schema/security"        xmlns:beans="http://www.springframework.org/schema/beans"        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"        xsi:schemaLocation="          http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd          http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd">            
Okay. This is an example from the spring official website. We didn't write any code! Okay, let's see what these configurations have done.
First, a filter named "springsecurityfilterchain" is defined in Web. xml. In the spring context file:
<Intercept-URL pattern = "/**" Access = "role_user"/>
Indicates that the user accessing any URL must have the "role_user" permission.
<User name = "Bob" Password = "12b141f35d58b8b3a46eea65e6ac179e" authorities = "role_supervisor, role_user"/>.
If you look at these definitions carefully, Are you confused:
<Intercept-URL pattern = "/images/*" filters = "NONE"/>
It indicates that access to "/images/*" does not require any permissions. Why does "/**" require "role_user" permissions? By the way, the order is very important, the URL permission judgment is based on the order from top to bottom matching the first.
<Form-login Login-page = "/login.htm" default-target-url = "/home.htm"/>
Defines the login page "login-page", and the displayed page "default-target-URL" after successful logon, and so on.
This is actually a complete spring security configuration. I have been able to work. Isn't it a sense of accomplishment? How did this happen? It's not shown at all!
Okay, let's get to know about it.

2. How does this happen.
1. Filter in Web. xml
    <filter>        <filter-name>springSecurityFilterChain</filter-name>        <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>    </filter>    <filter-mapping>        <filter-name>springSecurityFilterChain</filter-name>        <url-pattern>/*</url-pattern>    </filter-mapping>
Spring security protects the Web through filters. That's right, it's the "javax. servlet. filter" you think ".
The filter named springsecurityfilterchain intercepts all access requests for permission verification and access control.
"Springsecurityfilterchain" is a proxy that delegates intercepted requests to several filters of its proxy for verification. These filters form a chain to process requests in a certain order, which is also reflected in
"Chain" in the proxy name ". The order and quantity of these filters are configurable (not configurable in 3.0, but new filters can still be added to any location ), the best solution to this kind of requirement is dependency injection (IOC). Unfortunately, it is on the web. there is no IOC in XML, which is why it is a proxy: To obtain IOC support, the real configuration is in the context of spring.
In fact, org. springframework. web. filter. delegatingfilterproxy: the class that this class proxy is called springsecurityfilterchain. It is defined in springcontext. In spring security3.0, this class is automatically created by the framework and is Org. springframework. security. web. filterchainproxy instance. This will be discussed later.
2. spring-security-contect.xml
    <beans:beans xmlns="http://www.springframework.org/schema/security"        xmlns:beans="http://www.springframework.org/schema/beans"        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"        xsi:schemaLocation="          http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd          http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd">            
The configuration is very simple, because the namespace is introduced in spring security3.0, that is, using the namespace framework will help you do a lot of default work, the advantage is that the configuration is simple, the disadvantage is the details
And you don't understand why. Haha.
In the context of spring, there should be a class called "springsecurityfilterchain" according to the previous ideas. It defines a lot of filters to process requests. What you think is correct, but this detail is
<Http> This label is hidden.
What is the important mission of The filter chain is created (the covered details are finally displayed)
    <alias name="filterChainProxy" alias="springSecurityFilterChain"/>        <bean id="filterChainProxy" class="org.springframework.security.web.FilterChainProxy">        <sec:filter-chain-map path-type="ant">            <sec:filter-chain pattern="/images/*" filters="none"/>            <sec:filter-chain pattern="/**" filters="securityContextFilter, logoutFilter, formLoginFilter, requestCacheFilter,servletApiFilter, anonFilter, sessionMgmtFilter, exceptionTranslator, filterSecurityInterceptor" />        </sec:filter-chain-map>    </bean>
<Http> first, a "filterchainproxy" bean is created and each URL is configured with a default filter chain. Then, an alias for "springsecurityfilterchain" is added to "filterchainproxy, is in the web. the filter name configured in XML. A diagram from the official spring website clearly shows which filters are built in 
These filters are generated in advance by In spring security, there are a total of 17 types of web resource protection filters, most of which are generally not used, and four are required:
1. httpsessionintegrationfilter: Remember user information.
2. authenticationprocessingfilter: configure the user logon page, prompting the user to log on and verifying the user's identity. The filter has an attribute named authenticationentrypoint, which can be configured on the login page.
3. exceptiontranslationfilter: more user-friendly display of user exceptions.
4. filtersecurityinterceptor: Final judgment is made based on the user's permissions and the permissions required by the resources.
Well, here we have basically finished filtering. What have these filters done?
3. What are done in the filter?
In this framework, there are two main tasks: user authentication and access control. The filter that needs to do these two tasks will inject authenticationmanager (User Authentication) and accessdecsionmanager (Access Control ), first, authenticationmanager is responsible for user authentication, but it does not work. It distributes the activity to authenticationprovider. Spring security is a considerate framework and provides a large number of providers for users to use, such as database Authentication and JAAS authentication,
If there is no suitable solution, you can implement the authentication provider to create your own provider at any time. In fact, the provider itself does not work, and it distributes the activity to another interface, userdetailservice,
It actually works. It has a method: Public userdetails loaduserbyusername (string username) throws usernamenotfoundexception, dataaccessexception {}
Used to obtain user information. If the information exists, a userdetail object is returned. If the information does not exist, usernamenotfoundexception is thrown. This method must be implemented by the user. If the verification is successful,
Provider will generate an authentication object and put this object into Org. springframework. security. core. context. securitycontext is the security context of the current application. In this way, the current application can be used at any time to determine whether the current user has been authenticated and obtain information about the current user, such as the user name and password, permissions.
Besides, accessdecsionmanager is used to determine whether the current user has the permission to access a certain resource. It does not work and sends several accessdecisionvoters to vote for these interfaces. There are three votes: Yes, however, accessdecsionmanager has three different implementations: access is allowed if there is one vote; access is allowed if the majority are in favor; access is allowed only when the majority are in favor. This determines whether a user has the right to access a resource. In general, spring Security provides a default implementation: Org. springframework. security. vote. rolevoter is enough to meet most of the requirements, as long as the accessed resource requires role _ as the prefix permission, this class will vote by comparing the permissions owned by the user and the permissions required by the resource. Otherwise, the vote will be revoked. With this feature, you can set your own user permissions and resource permissions (using role _ as the prefix). Generally, you do not need to implement it yourself. Of course, the rule with the "role _" prefix can be changed through settings.
This is almost the same. Let's talk about a bug at work:
When a user reports an exception on the login page, for example, when the database is down or the network is disconnected, an error is always reported: "This user has no permission." This is indeed inappropriate. After finding the method loaduserbyusername in the implementation class of userdetailservice, No matter any exception occurs, it will catch and then throw the usernamenotfoundexception. If authentication fails in filter: authenticationprocessingfilter, it will get the failed exception and write the exception to the session. The key value is "spring_security_last_exception", so that the exception can be obtained from the session in JSP, tell the user what the error is. No matter what the error is, throwing usernamenotfoundexception causes the JSP to only see this exception and always report the error "this user has no permission. The correction method is very simple, and several implementations inherit the org. springframework. security. core. authenticationexception (the parent class of usernamenotfoundexception) is thrown when different errors are caught and then judged in JSP.
Spring Security provides a JSP tag library to facilitate obtaining the most secure information on the JSP page. If you are interested, let's take a look at it. I will not detail it here.
The write is messy. Please leave it blank if any error occurs. Thank you.