This article introduces the method of Spring Security to control authorization and shares it with you, as follows:
Use the authorization method to configure authorization
Each Spring Security control authorization expression (hereinafter referred to as an expression) actually corresponds to an authorization method in the API, which is the processing method when the requested URL permissions are configured. For example:
@Overrideprotected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() .antMatchers(HttpMethod.DELETE, "/user/*").hasRole("ADMIN") .antMatchers("/index").permitAll() .antMatchers("/pay").hasAnyRole("WE_CHAT_PAY", "ALI_PAY") .antMatchers("/debug").hasIpAddress("192.168.1.0/24");}Use authorization expressions to authorize requests for multiple permissions
So, when do you need to use expressions for authorization processing? The permission requirements of a security application are often complex and diverse. For example, the debugging request of a project expects the visitor to have both administrator rights and must access it through the internal LAN of the company. Under such requirements, the methods provided by the Security API cannot be met only because these authorization methods cannot be called continuously.
You can use authorization expressions to solve this problem:
@Overrideprotected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() .antMatchers("/debug") .access("hasRole('ADMIN') and hasIpAddress('192.168.1.0/24')");}Authorization expression example
| expression | illustrate |
|---|---|
| permitAll | Return true forever |
| denyAll | Return false forever |
| anonyous | If the current user is an anonymous user, return true |
| rememberMe | If the current user is rememberMe, return true |
| authenticated | If the current user is not anonymous (authenticated) user, return true |
| fullAuthenticated | Return true if the current user is neither anonymous nor rememberMe user |
| hasRole(role) | If you have the specified role role permissions in the current user permissions collection (when matching, 'ROLE_' will be added before the permissions you specified, that is, if you determine whether there is "ROLE_role" permission), return true. |
| hasAnyRole(role1, role2, ...) | Return true if you have any role permissions in the current user permissions collection |
| hasAuthority(authority) | Return true if the current user permissions have authority (match whether there is "authority" permission) in the current user permissions collection. |
| hasAnyAuthority(authority) | Return true if you have any permissions in the current user permissions collection |
| hasIpAddress("192.168.1.0/24") | Fanhui true when sending the requested IP match |
Role-Based Access Control RBAC (Role-Based Access Control)
Perhaps you will think that the above method can meet the security authorization management of most applications. However, in fact, the authorization of enterprise-level applications is often based on dynamic changes in database data. If string splicing is used above, it will not only be extremely unfriendly to developers (every change in personnel means that code needs to be changed, which is obviously unreasonable), but the performance of the application will also be reduced accordingly. So, how to solve it?
Data Model
A general RBAC data model generally requires five tables (three entity tables and two relationship tables). The three entity tables include user table, role table, and resource table. The two relationship tables include. The relationship between them is as follows:
RBAC data model
User table
Any user must have a user table. When a company changes personnel, business personnel (such as human resources) will add and delete the data table.
Role List
What identities do the company have, such as the president, vice president, department manager, etc., and there are business personnel who operate the data on the table based on the specific situation of the company.
Resource List
Store resources that require permission control. Since we actually use URLs when we use control authorization, business personnel do not organize data entries according to URLs, but instead operate in the form of a view interface. So in this table, the menus and buttons presented to business personnel and the URLs that are controlled by the permissions.
User-role relationship table
There is a many-to-many relationship between the user table and the role table (user id and role id). A user can be multiple roles (a user can be both a department manager and an administrator), while a role often corresponds to multiple users.
Role-resource relationship table
The role table and the resource table () are also a many-to-many relationship. A role can access multiple resources (buttons or menus, etc.), and a resource can also be accessed by multiple roles.
spring security also supports custom expressions to do the job, like this
The above is all the content of this article. I hope it will be helpful to everyone's learning and I hope everyone will support Wulin.com more.