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

This article mainly explains "how to refine the permission granularity in Spring Security". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to refine the permission granularity in Spring Security".

1. Privilege management model

If we want to refine the permission granularity, we will inevitably involve some permission models, such as ACL, RBAC, DAC, MAC, ABAC, PBAC and so on.

Among these numerous permission models, the one we use more often is that RBAC,ACL is also used by some projects, while others are relatively less used. So Brother Song here focuses on introducing ACL and RBAC.

1.1 ACL

ACL is an ancient access control model. The full name is Access Control List in English and access control list in Chinese. This is a resource-oriented access control model, and all permissions are configured for resources.

Here's how it works:

For each resource in the system, an access list is configured, which records the CURD permissions of the user / role to the resources. when the system needs to access these resources, it will first check whether the current user has access rights in the list, and then determine whether the current user can perform the appropriate operation.

The use of ACL is very simple, and you can implement it in minutes to figure out how it works. But ACL has an obvious disadvantage, which is that it needs to maintain a large number of access lists. The problems caused by a large number of access control lists are performance degradation and complex maintenance.

1.2 RBAC

RBAC (Role-based access control) is a role-based access control, and it is also a widely used permission model at present. It has many different variants. Song GE will write a special article to introduce RBAC, which is only a simple popular science.

The RBAC permission model classifies users by role, and determines whether the user has the right to operate on a resource through the role of the user. RBAC simplifies the management of users and permissions. It associates users with roles, roles and permissions, permissions and resources. This mode makes user authorization management very simple and easy to maintain.

1.3 other

The use of the following is less common, friends can do an understanding, interested friends can also study by themselves.

ABAC: this is an attribute-based access control.

PBAC: this is a policy-based access control.

DAC: in addition to permission control, principals can also grant permissions to other principals.

MAC: resources can be accessed by which categories of principals and what levels of resources can be performed by principals. Access is allowed when both conditions are met.

2.ACL

Next, Brother Song is going to give you a detailed introduction to the permission model of ACL. I will write an article on RBAC later, so I won't discuss it in this article.

The full name of Acl is Access Control List, which is what we call access control list. It is used to control the access rights of objects. One of the core ideas of Acl is to grant certain permissions of an object to a user or a role. The relationship between them is many-to-many, that is, a user / role can have multiple permissions of an object, and the permissions of an object can also be held by multiple users / roles.

Take a simple example:

Now there is a User object, which has permissions for query, modification, deletion, and so on. You can assign these permissions to a user or a role. When the user has these roles, he or she has the permission to perform the corresponding operations.

From this point of view, Acl is a very fine-grained permission control, which specifically controls the operation permissions of an object. All these permissions are recorded in the database, which brings another problem is that the amount of permission data that needs to be maintained is very large, which is not conducive to later expansion. Of course, for a simple system, it's okay to use Acl, and there's no problem.

2.1 Core concept

Next let's take a look at some of the core concepts in Acl.

Sid

Sid represents the user and the role, it has two kinds: GrantedAuthoritySid and PrincipalSid, the former represents the role, the latter represents the user. In Spring Security, the user and role information is stored in the Authentication object, that is, Sid is extracted from the Authentication object, and the extracted value is GrantedAuthoritySid+PrincipalSid, not one of them. The specific extraction method is SidRetrievalStrategyImpl#getSids. The relevant source codes are as follows:

Public List getSids (Authentication authentication) {Collection authorities = roleHierarchy .getReachableGrande authorities (authentication.getAuthorities ()); List sids = new ArrayList (authorities.size () + 1); sids.add (new PrincipalSid (authentication)); for (GrantedAuthority authority: authorities) {sids.add (new GrantedAuthoritySid (authority));} return sids;}

This Sid can be simply understood as the permissions of the current user (this statement is not very accurate and can be approximately understood).

ObjectIdentity

It is official to say that ObjectIdentity is a domain object, which is a bit of a mouthful. In fact, this is the object you want to operate on.

For example, I have a User object, and if I go directly to record what operations can be performed on the User object, this will lead to high coupling and. So we need to decouple it and describe all the objects that need to be manipulated through ObjectIdentity, which ensures that the permission system is not bound to the specific business.

There are two key methods in ObjectIdentity, getType and getIdentifier. Generally speaking, the getType method returns the full path of the real object class, while the org.javaboy.acl.model.User,getIdentifier method, for example, returns the id of the real object. With these two methods, you can lock an object.

Acl

As you can see from the name, this is the core scheduling part of the whole system.

An Acl object is associated with an ObjectIdentity, and an Acl object also has a Sid. This Sid indicates to whom the Acl belongs? Whoever belongs to it can modify or even delete the Acl object.

AccessControlEntry

AccessControlEntry is abbreviated to ACE, and an AccessControlEntry object represents a permission record. Each AccessControlEntry corresponds to an Acl, and an Acl object corresponds to multiple AccessControlEntry. With this layer of correspondence, it is equivalent to knowing which object this permission operates on.

The AccessControlEntry then contains a Sid and a Permission object, indicating that a Sid has certain permissions.

As you can see, Acl+ACE describes that a Sid can have some kind of Permission of an ObjectIdentity.

Permission

This is the specific permission object. It seems to be affected by Linux, which uses a permission mask and supports up to 232-1 permissions.

Five Spring Security types are defined by default:

Public class BasePermission extends AbstractPermission {public static final Permission READ = new BasePermission (1

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.