Shulou(Shulou.com)05/31 Report--

This article mainly shows you "RBAC example analysis", the content is simple and easy to understand, organized clearly, I hope to help you solve doubts, let Xiaobian lead you to study and learn "RBAC example analysis" this article bar.

What is Rights Management?

Basically, the system involved in user participation should be managed by permission, which belongs to the category of system security. Permission management realizes the control of user access to the system, and controls that users can access and only access their authorized resources according to security rules or security policies.

Authority management includes user identity authentication and authorization, referred to as authentication authorization. For the resource that needs access control, the user must first pass the identity authentication, and after the authentication, the user has the access right of the resource before accessing.

user authentication

Identity authentication is the process of determining whether a user is a legitimate user. The most common simple authentication method is that the system checks the user name and password input by the user to see if 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 fingerprints, fingerprints are presented; for credit card systems such as hardware keys, credit cards are required.

Username Password Authentication Process

key object

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

Subject: Subject

The user who accesses the system, the subject can be a user, a program, etc., and those who authenticate are called subjects;

n Principal: Identity information

It is the identity of the subject for identity authentication. The identity must be unique, such as user name, mobile phone number, email address, etc. A subject can have multiple identities, but it must have a primary identity.

n credential: credential information

Security information that only the subject knows, such as passwords, certificates, etc.

authorized

Authorization, or access control, controls who can access which resources. After authentication, the principal needs to assign permissions to access system resources. Some resources cannot be accessed without permissions.

authorization process

Orange in the figure below is the authorization process.

key object

Authorization can be simply understood as who performs How on what(which):

n Who, or Subject, requires access to resources in the system.

n What, i.e. Resource, such as system menu, page, button, class method, system commodity information, etc. A resource includes a resource type and a resource instance. For example, commodity information is a resource type, commodity type t01 is a resource instance, and commodity information number 001 also belongs to a resource instance.

n How (Permission) specifies the operation permission of the subject to the resource. Permission has no meaning outside the resource, such as user query permission, user add permission, calling permission of a certain class method, modification permission of user No. 001, etc. Through the permission, it is known which operation permission the subject has for which resources.

Permission is divided into coarse-grained and fine-grained permissions. Coarse-grained permissions refer to permissions on resource types, and fine-grained permissions refer to permissions on resource instances.

The relationship between subject, resource and permission is shown in the following figure:

permissions model

The subjects, resources, and permissions in the previous section are represented by data models.

Subject (account, password)

Resources (resource name, access address)

Permission (permission name, resource id)

Role (Role Name)

Role and permission relationship (role id, permission id)

Relationship between subject and role (subject id, role id)

As shown below:

Usually, resources and permission tables are merged into a permission table in enterprise development, as follows:

Resources (resource name, access address)

Permission (permission name, resource id)

Consolidated into:

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

The above figure is often referred to as a general model of permission management, but enterprises will modify the above figure according to the characteristics of the system itself during development, but users, roles, permissions, user role relationships, and role permission relationships need to be understood.

distribution of competences

Assign permissions to the entity. The entity is only allowed to operate resources within the permission range. For example, assign commodity modification permission to user u01, and user u01 can only modify commodities.

Permission assignment data usually needs to be persisted, creating tables based on the above data model and storing user permission information in the database.

authority control

The system does not know whether the subject has access rights and needs to control the user's access.

role-based access control

RBAC Role-Based Access Control is role-centric access control. For example, the role of the subject is the general manager, and you can query enterprise operation reports and employee salary information. The access control process is as follows:

The judgment logic code in the above figure can be understood as:

if(Subject.hasRole("General Manager Role id")){Query Salary}

Disadvantages: The granularity of access control based on role is coarse. If the role required for querying salary in the above figure changes to general manager and department manager, the judgment logic needs to be modified to "Judge whether the role of the subject is general manager or department manager." The system scalability is poor.

The modification codes are as follows:

if(Subject.hasRole("General Manager Role id")|| Entity.hasRole("Department Manager Role id"){Query Salary}

resource-based access control

RBAC Resource-Based Access Control is resource-centric access control. For example, the entity must have the permission to query salary before it can query employee salary information. The access control process is as follows:

The judgment logic code in the above figure can be understood as:

if(Entity.hasPermission("Salary Query Permission ID")){Query Salary}

Advantages: The permission identification for querying salary is defined during system design. Even if the roles required for querying salary change to general manager and department manager, you only need to add "Query Salary Information Permission" to the permission list of "Department Manager Role". The judgment logic does not need to be modified, and the system has strong scalability.

Rights Management Solutions

Coarse and fine particle sizes

What are coarse and fine particle sizes?

The management of resource types is called coarse-grained permission management, that is, only control to menus, buttons and methods. For example, users have the permission to manage users and the permission to export order details. The control over resource instances is called fine-grained permission management, i.e., the permission is controlled to the data level. For example, users are only allowed to modify the employee information of their own department, and users are only allowed to export the order details created by themselves.

How to achieve coarse and fine particle size

Coarse-grained permission management can easily be done at the system architecture level, that is, system function operations use uniform coarse-grained permission management.

For fine-grained permission management, it is not recommended to make it a function at the system architecture level, because the control of data level is the business requirement of the system, and the possibility of business function change with the change of business requirement is very high. It is recommended that the permission control of data level be personalized development at the business layer, for example: Users are only allowed to modify the product information created by themselves. Verification implementation can be added to the service interface. The service interface needs to pass in the ID of the current operator, which is compared with the ID of the product information creator. If it is inconsistent, the product information cannot be modified.

The above is "RBAC sample analysis" all the content of this article, thank you for reading! I believe that everyone has a certain understanding, hope to share the content to help everyone, if you still want to learn more knowledge, welcome to pay attention to the industry information channel!

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.