RBAC introduction _ dynamic node Java school arrangement, rbacjava

RBAC introduction _ dynamic node Java school arrangement, rbacjava

What is permission management?

Permission management is basically required for systems involving users. permission management belongs to the category of system security. permission management controls user access to the system, users can access and can only access their authorized resources according to security rules or security policies.

Permission management consists of two parts: user identity authentication and authorization. For resources that require access control, the user is authenticated first. After authentication, the user has the access permission to the resource to access.

User identity authentication

Identity Authentication is the process of determining whether a user is a legal user. The most common simple authentication method is that the system checks the user's user name and password to check whether it is consistent with the user name and password stored in the system, to determine whether the user identity is correct. For systems such as fingerprint, the fingerprint is displayed. For card swiping systems such as hardware keys, you need to swipe the card.

 User name and password authentication process

 

Key objects

The following key objects need to be understood in the flowchart above:

Subject: Subject

Users who access the system can be users and programs. The subjects for authentication are called subjects;

NPrincipal: Identity information

Is the identity of the subject for identity authentication. the identity must be unique, such as the user name, mobile phone number, and email address. A subject can have multiple identities, however, you must have a Primary identity (Primary Principal ).

NCredential: Credential information

It is only the security information that the subject knows, such as passwords and certificates.

Authorization

Authorization, that is, access control, controls who can access which resources. After the subject performs identity authentication, it must assign permissions to access system resources. Some resources cannot be accessed without permissions.

Authorization process

Orange indicates the authorization process.

 

Key objects

Authorization can be simply understood as who's action on what (which:

N Who, that is, the Subject (Subject), the Subject needs to access resources in the system.

N What refers to resources, such as system menus, pages, buttons, class methods, and system product information. Resources include resource types and resource instances. For example, if the product information is a resource type, the product type t01 is a resource instance, and the product information numbered 001 is also a resource instance.

N How, Permission/Permission (Permission), specifies the subject's Permission to operate on the resource, the Permission does not make sense to leave the resource, for example, the user query permission, the user add permission, the call permission of a class method, and the modification permission of the user numbered 001 are used to determine which resources the subject has permission to perform.

Permission can be divided into coarse particles and fine particles. coarse particles permission is the permission on the resource type, and fine granularity permission is the permission on the resource instance.

The relationships between subjects, resources, and permissions are as follows:

 

Permission Model

The subjects, resources, and permissions in the preceding section are represented by the data model.

Subject (account, password)

Resource (Resource Name, access address)

Permission (permission name and resource id)

Role (role name)

Relationship between roles and permissions (role id and permission id)

Subject and role relationship (subject id and role id)

For example:

 

The resource and permission tables are usually merged into a permission table in enterprise development, as follows:

Resource (Resource Name, access address)

Permission (permission name and resource id)

Merged:

Permission (permission name, Resource Name, resource access address)

 

It is often referred to as the general model of permission management. However, enterprises will modify the model based on the characteristics of the system during development, however, users, roles, permissions, user-role relationships, and role-Permission relationships must be understood.

Permission allocation

Assign permissions to the subject. The subject can only perform operations on resources within the permitted range. For example, if you assign the item modification permission to u01 users, u01 users can only modify the item.

Data for permission allocation usually needs to be persistent. Create a table based on the above data model and store the user's permission information in the database.

 Permission Control

The user has the permission to operate resources within the permitted range. The system does not know whether the subject has the access permission and needs to control the user's access.

Role-Based Access Control

Role-Based Access Control (Role-Based Access Control) is a Role-centric Access Control. For example, if the Role of the subject is the general manager, you can query the enterprise operation report and employee salary information, the access control process is as follows:

 

The judgment logic code in can be understood:

If (subject. hasRole ("General Manager role id") {query salary}

Disadvantage: the granularity of Role-Based Access Control is coarse. If the roles required for wage query are changed to the general manager and department manager, in this case, you need to modify the judgment logic to "determine whether the role of the subject is a general manager or department manager", and the system has poor scalability.

The modification code is as follows:

If (subject. hasRole ("General Manager role id") | subject. hasRole ("department manager role id") {query salary}

Resource-Based Access Control

Resource-Based Access Control (RBAC) is a Resource-centric Access Control. For example, a subject must have the permission to query the employee's salary information, the access control process is as follows:

The judgment logic code in can be understood:

If (subject. hasPermission ("querying wage permission IDs") {querying wages}

Advantage: the permission ID for querying wages is defined during system design, even if the roles required to query the salary change are the General Manager and department manager, you only need to add the "permission to query the salary information" to the "department manager role" permission list. The judgment logic does not need to be modified, high system scalability.

Permission management solution

Coarse granularity and Fine Granularity

What is coarse granularity and Fine Granularity?

The management of resource types is called coarse-grained permission management, that is, only menu, buttons, and methods are controlled. For example, a user has the permission of user management and the permission to export order details. Resource instance control is called fine-grained permission management, that is, control to data-level permissions. For example, you can only modify the employee information of the department, and you can only export the Order details you have created.

How to achieve coarse granularity and Fine Granularity

For coarse-grained permission management, you can easily implement system architecture-level functions, that is, you can use uniform coarse-grained permission management for system function operations.

For fine-grained permission management, it is not recommended to implement system architecture-level functions, because data-level control is the business needs of the system. As the business needs change, business functions may change greatly, we recommend that you control data-level permissions for personalized development at the business layer. For example, users can only modify their own product information and add verification implementation on the service interface. The service interface must pass in the identity of the current operator, the product information cannot be modified if it is inconsistent with the product information creator ID.