Shulou(Shulou.com)06/03 Report--

What is the role of Spring Security, roles? This article starts from the source code, a detailed analysis of the role of Spring Security roles, interested friends can refer to, hope to help you.

When we design the role permission control, it generally includes three parts: account (users), role (roles) and authority (authorities).

1) an account generally corresponds to one or more roles

2) A role corresponds to multiple permissions (authorities), and in turn, a permission corresponds to multiple roles

3) the account is only associated with roles, and has a relationship with permissions indirectly through roles.

4) roles are not fixed, but can be created dynamically, and the permissions of each role can be adjusted flexibly.

5) after the detailed design of the system, which permissions have been determined, the hierarchical structure and number of permissions have nothing to do with accounts and roles.

Based on the above instructions, we explain the account, role and permissions of Spring Security from the point of view of source code.

Spring Security workflow: through the account logged in, find the corresponding role / permission of the account, and convert the custom permission set into the permission set approved by Spring Security List, and then combine the custom account, password, and new permission set to create an account instance approved by Spring Security, and then control the permissions according to the custom authentication rules.

I won't talk about the details of how to create accounts, roles, permissions, user authentication and authentication, because this is not the focus of this article. Interested readers can watch my video introduction: https://edu.51cto.com/course/21185.html, in which there are details on how to develop a practical Spring Security role access control module.

The key point is to see how Spring Security uses roles and permissions through the application of role permission control.

There are four ways of authentication:

HasRole (String role)

HasAnyRole (String... Roles)

HasAuthority (String authority)

HasAnyAuthority (String... Authorities)

In the source class SecurityExpressionRoot.java, let's take a look at the implementation of these four ways:

Do you see anything from the picture above?

HasRole (String role)-"hasAnyRole (String...) Roles)-"hasAnyAuthorityName"

HasAuthority (String authority)-"hasAnyAuthority (String...) Authorities)-"hasAnyAuthorityName"

Whether role-based or permission-based, authentication is finally implemented in the hasAnyAuthorityName method.

Follow me, let's continue to dig down to see what's in the hasAnyAuthorityName method. Notice the parameters passed when calling hasAnyAuthorityName in the above code, one of which is

The other is

The corresponding is an implementation method.

From the hasAnyAuthorityName method, we can see that one or more roles / permissions passed in are looked up in the permissions of the logged-in user.

As you can see, roles and permissions are mixed together for authentication (beside the point, you look at the code written by the gods and notice the var5, var6 and var4 in it. What is this? It seriously does not conform to the naming convention.

So how does Spring Security distinguish between permissions and roles in the collection? let's continue to peel off the cocoons and look at the getRoleWithDefaultPrefix (prefix, role) method in this method.

See the code above is clear, and the instructions are as follows:

If the role name / permission name passed in is null, return null directly

If the role name / permission name passed in is not null, determine whether the parameter defaultRolePrefix prefix is empty and its length. If it is not empty and the length is not 0, the parameter passed in is the role name, then continue to determine whether it starts with "ROLE". If not, add the prefix "ROLE" to the name and return the new name.

If this is not the case, that is, if the parameter is a permission name or a role name with a "ROLE_" prefix, the string parameter passed in is returned directly.

After looking at the above partial source code parsing, what conclusion can we draw (take roles and permissions stored in the database as an example):

1. There is no essential difference between the original roles and permissions, and the authentication takes exactly the same channel.

2. Roles can be prefixed with or without "ROLE" when carrying out permission control, but role names must be prefixed with "ROLE" when they are defined in the database.

3. There is no mapping relationship between roles and permissions. Roles are roles and permissions are permissions, which is very different from the requirements of roles in our practical application.

4. The roles in practical applications are solidified into the code, which is not in line with the actual requirements. In practical applications, permissions as child nodes can be written to death, while roles as a collection of all or part of permissions should be flexibly adjusted.

5. Both role authentication and permission authentication are only based on the name of the role / permission, so the name of the permission should be unique.

In addition, from the source code analysis of Spring Security, we can also find that we can inherit roles through RoleHierarchy (by default, admin login can only access / admin, not / user;, and user login can only access / user), but in actual projects, the main emphasis is on role flexibility, not inheritance.

Therefore, the management of roles and the mapping of roles and permissions need to be implemented by ourselves.

After reading the above, do you have any further understanding of the role of Spring Security? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel. Thank you for reading.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.