Summary of how SpringSecurity controls permissions Spring uses a chain of Filter to determine permissions. As shown in the following figure: Spring predefines many filters out of the box for developers to use directly. Usually (some filters are abstract), each filter corresponds to an element of the configuration file (in some cases, it may be an attribute). For example, authentication _ processing _ filter corresponds to the http/form-login element in the configuration file. If the filter provided by Spring can't meet the permission function of the system, the developer can customize the filter and then put it in a certain position of a FilterChain. You can replace the filters in the original filter chain, or you can put them before or after the filters. In a word, SpringSecurity uses the FilterChain mode to judge permissions. Spring provides some filters and also supports developers to define filters. The integration with WEB system uses JavaEE's Filter (non-Spring's Filter) mechanism to simply "pull" the url that needs permission judgment to Spring's FilterChain. Generally speaking, all URLs are introduced into the FilterChain. Of course, you can also configure the url that needs permission judgment in web.xml (configure filter-mapping/url-pattern). Spring's configuration file also supports filtering out urls that do not require permission judgment (configuring http/intercept-url elements). Control content SpringSecurity provides control over the following contents:1.url; ; 2.beanmethod3.httpsession .Url: It can be divided into url requiring permission judgment, url not requiring permission judgment and login form url. Through my reading of spring-related posts and references, I need an authoritative url. Only role judgment, that is, to judge whether the current user has the specified role. Beanmethod:Spring supports permission judgment on Servicelayermethod. Through my reading of spring-related posts and references, I am also limited to making role judgments. There are two configurations: 1. Write in Java source code, such as @Secured("ROLE_TELLER ") (this method can only be accessed by users with TELLER role, otherwise an exception will be thrown); 2. Write it in the configuration file, such as: (All set methods of this bean can only be accessed by users in the ADMIN role, otherwise an exception will be thrown). Httpsession: Controls whether and how many times the user name can log in repeatedly, not how many times the password is retried. In addition, SpringSecurity also provides the following functions: 1.rememberme, remember me; 2.form-login login control; 3. Multiple authentication functions; 4. User password encryption and "salt adding" function; 5.http protocol control; 6. Access port control; 7. Pre-call and. After calling. Rememberme, remember me: Remember that the browser used cookie to remember the user name and password and automatically logged in? It seems so (I don't know if I misunderstood it, I don't think so. I can't believe it. Through this function, developers can use spring to customize tags on the login page. Form-login login control: Some pages are not allowed to be accessed anonymously, so when these pages are accessed anonymously, the form-login window (or page) will pop up (or go to). Here are two more questions: 1, how to verify after entering the user name and password; 2. Whether the password needs to be encrypted and how to encrypt it. Multiple authentication functions: Spring provides rich user authentication functions. What does certification mean? For example, you told me "I am a fairy". Then I will ask you, "What makes you prove that you are a fairy?" This is certification. Authentication means are generally user name/password, usbkey, ldap, etc. stored in the database table. Generally speaking, we all use user names/passwords. User password encryption and salt function: whether the password is md5 or sha encryption algorithm. If we encrypt the password, we not only want to encrypt the password, but also want to encrypt the user name and password together as the encrypted password. Then use salt. Salt support also reads other attributes of the user, not just the user name. Http protocol control: which URLs must https visit? Which URLs must be accessed via http? What can I have both? With this configuration. Access port control: similar to http protocol control, it controls the relationship between url and access port. Pre-call and. Post-call: Do you make permission judgment before or after the method call? It's usually called before. In some cases, it is called post. Specific examples can be found in official documents (Section 22.3). Fine-grained permission control From the above analysis, it can be seen that the permission judgment of url and method is limited to the permission judgment of user role. In fact, Spring uses a voting mechanism to judge permissions. User role permissions are also a kind of voting. The word voting doesn't sound easy to understand. Ex: The board of directors meets, and all shareholders vote to decide whether the resolution is passed. Spring's role voters will only vote once. We usually say that voting requires at least two votes, one vote is not one vote. There are three results in the spring vote: permission, rejection and abstention. Abstain? I am really dizzy. Hehe, in that case, I also abstained. So how does the voter integrate into the filter of Spring? Spring filters are usually supported by an administrator. For example, accessDecisionManager can be provided by RoleVoter and BasicAclEntryVoter. AccessDecisionManager makes decisions according to the voting results of RoleVoter and BasicAclEntryVoter. Fine-grained (data-level) access control, SpringSecurity provides the model and related implementation. Let me briefly talk about this model. For example, Zhang San authorized to inquire about customer information in North China and Li Si authorized to inquire about customer information in South China. Then all customer records will be marked first (equivalent to getting an id), and then Zhang San will be authorized to access all customers in North China in the acl-entry table; Give permission to all customers in South China of Li Si. The table records are roughly as follows: the authorized user authorizes the operation of Zhang San Huabei Power Customer 1 Reading Zhang San Huabei Power Customer 2 Reading Li Si Huanan Power Customer 1 Reading ... The disadvantages of this mode are very obvious: 1 binds business data, and the permission table needs to be maintained for adding/deleting business data; 2. In the case of a large amount of data, the system is inefficient. Therefore, developers need to write their own voting devices. Our ideal rights management customers' demand for rights management refers to the end users we serve, not the software developers. Customer's demand for rights management can be roughly summarized as: 1. Manage roles and role permissions independently and flexibly, and give roles to relevant users of the system; 2. Data security. The data displayed in the system conforms to the authority, the search of data in the system must also be within the corresponding authority, and the addition, modification and deletion of system data must conform to the authority; 3. Buttons, menus, data, etc. No function should not appear on the interface. Managing users, roles, permissions and their relationships, this typical RBAC model is very easy without any difficulty. The difficulty lies in data-level access control. This is directly related to the business, and it is also the most complicated. It often changes because the customer needs are not well expressed, the developer needs are not well understood, and the structure of the system framework library table changes. This change requires not only coding, but also retesting. Even this change will affect other modules and even the whole system. The system development has undergone several changes, and the code is littered with if/else and sql statements. Cause bad smell Our ideal authority management Our expected authority management should have the following characteristics: 1. Role-level permissions can be realized; Can achieve data-level permissions; 2. Simple and easy to operate, and can meet various requirements; 3. Strong ability to cope with changes in demand; 4. It is better to have relevant interfaces, such as permission management interface, role management interface, relationship maintenance interface between roles and permissions, and relationship maintenance interface between users and roles. If there is no interface, it is acceptable. After all, these pages need to be used by end users, and different users have different requirements for the interface of the system. So we don't expect a unified management interface. Evaluation of SpringSecurity In the world of SpringSecurity, we can distinguish which resources can be accessed anonymously, which require role permissions, and which pages provide login functions. How to authenticate users and how to encrypt their passwords. Which resources must use https protocol, and what is the corresponding relationship between resources and access ports. The following comments on the advantages and disadvantages of SpringSecurity. Advantages Generally speaking, SpringSecurity has the following advantages: 1. It provides a set of authority framework, which is feasible; 2. A lot of user authentication functions are provided, which can save a lot of development work; 3. Providing the function of role judgment, which is both an advantage and a disadvantage; 4. Provide controls such as form-login and rememberme. Among them, 2 and 4 are of little use to China developers (I don't know much about foreign systems). Most of our systems adopt the user name/password authentication mode, and most companies have reusable codes. The functions of form-login and rememberme are not difficult to develop, and there are not many places available. Disadvantages I personally think that SpringSecurity has the following disadvantages: 1. Roles are "encoded" into configuration files and source files, so end users cannot create roles. But end users want them to control the role themselves. Because in the process of project implementation, customers may not be sure which roles are available and how to assign them to system users. Most roles cannot be determined until the system is online. These codes are: a) permission control of a)url; B) b) access control of Java methods, @ secured ("is _ authenticated _ anonymous"); C) access control of c)java methods; 2. The widely used model RBCA is not reflected in SpringSecurity; 3.SpringSecurity does not provide a good fine-grained (data-level) permission scheme, and the provided default implementation has a large maintenance workload, which is almost unavailable when there is a large amount of data; 4.SpringSecurity does not provide any maintenance interface for the relationship among users, roles and permissions. However, from the perspective of SpringSecurity, there really is no need to have an interface. The direct relationship between role creation, roles and permissions has been "coded" into configuration files and source files; 5.SpringSecurity is difficult to learn, and there are still many configuration files. I admit that there are many experts, but we also see many newcomers joining the field of software development. Personally, I think it is not worthwhile to pay such a big learning cost and get such a little profit. Ps: I have been creating a "rights management" circle in JavaEye for almost 2 weeks, attracting many netizens to come in. I feel very happy and honored. Since SpringSecurity is still widely used, I plan to study hard and share my learning experience with you.