Role management (RBAC)-based Permission System

The permission system has two concepts:

 

Coarse granularity:Indicates the class (model) level, that is, only the type of the object is considered, not a specific instance of the object. For example, in the management of the contract category (contract), creation, deletion, and other operations, all users are treated equally without distinguishing specific object instances (sales contracts and production contracts ). Fine Granularity:It indicates the instance level, that is, the instance of the specific object needs to be considered. Of course, the fine granularity is to consider the specific instance only after the coarse granularity object category is considered. For example, in sales contract management, the contract owner has the permission to view, modify, and delete the contract. Other users only have the permission to view the contract. Permission System Design Principles:The permission logic works with the business logic. That is, the permission system provides services for the business logic. Fine-grained permission issues do not make common sense because of their business relevance. They are understood as part of the "business logic. For example, the requirement is: "A contract can only be deleted by its creator, users in the same group as the creator can be modified, and all users can browse ". This is both a fine-grained permission issue and a business logic issue. Here it is a business logic problem, which is not considered in the entire permission system architecture design. Of course, the permission system architecture must also support such business logic. In other words, the system provides sufficient but not full control capabilities. That is, the design principle is: "The system only provides coarse-grained permissions, and fine-grained permissions are considered to be the responsibility of business logic ".

Permission Logic Bytes À Coarse granularity Business Logic Bytes À Fine Granularity Concept: Object:It refers to various functional modules, business models, Business Objects, and interface elements in the system. It is all objects accessible to the subject. The access permission varies depending on the object type. (1)System function module: in addition to the public interface and public modules, all the other modules are business function modules. business operations are completed in the design phase, so there is no concept of an instance. You can directly authorize a role. (2)Interface elements: in addition to the function menu being controlled, if you want to control the interface elements of the function module, the interface elements of the function module also need to be defined. Most interface elements contain related business function operations, therefore, it can be processed in a unified manner with the data model. (3)Business Model, Business Object: the business model is our domain model. In the design and development phase, developers have defined the relevant business operations, that is, the corresponding permissions. The business object is the instantiation domain object of our business model. Is created when the system is running, so its permissions are also created when the system is running.

Coarse granularity		Fine Granularity
Domain Model	Business model, such as contract model)	Domain object	An instance of a business model, such as a sales contract object)

 

Privilege (operative, permission ):Is an object related operation. This permission is bound to a specific object. For example, the publishing permission of a department news is called "Department news publishing permission ". This indicates that the privilege is a publishing permission and is a publishing permission for resources such as department news. Permissions include system-defined permissions and user-defined permissions. You can specify exclusion and inclusion relationships between user-defined permissions (for example, read, modify, and manage three permissions, management permissions include the first two permissions ). Role:Is a set of permissions, and is a coarse-grained and fine-grained (business logic) interface. A permission framework Software Based on coarse-grained control, the external interface should be a role, and the specific business implementation can directly inherit or expand the content of the rich role, the role is not like the specific entity of the user or group, it is an abstract generic name of the interface concept. Role inheritance is embodied by group, so the role inheritance relationship is not considered. However, role can be associated with related groups to facilitate authorization. GROUP:User Group, the unit and carrier for permission allocation, and the organizational relationship is directly mapped. Permissions are not assigned to specific users. A group can contain groups (to inherit permissions ). A group can contain users who inherit group permissions. Group must be inherited. That is, you must specify the group in which the parent of the group is created. In terms of coarse-grained control, it can be considered that as long as a user directly or indirectly belongs to a group, it will have all operation permits for this group. In terms of fine-grained control, in the judgment of the business logic, the user should only pay attention to the group it directly belongs to, to determine whether it is "same group ". However, the inheritance of group leads to the opposite of permission inheritance and organizational relationship. The upper-level permissions of organizational relationship are higher, so it is a type of reverse inheritance. User:Pure users and permissions (operative? Permission? Privilege) is separated and can only be associated with the corresponding permissions through role. Link: Privilege Limit N: 1 À Resource Role Limit N: N À privilege Group Limit N: N À user Group Limit N: N À role User Limit N: N À role

 

 

Operation Mode of the permission system: (1 ): Create resources and permissions:Here we need to consider coarse granularity from the aspect of Fine Granularity 2: developers Define relevant operations when designing the domainmodel. For example, the domainmodel contractmodel has been defined by the developer during design, such as viewing and modifying the model. By default, all roles are the same. Fine Granularity: When you create a domainmodel instance domainobject, specify related permissions and assign permissions. For example, only the creator of a sales contract has the modification permission, and the person in the same group can only view the permission. (2 ): Assign permissions:The Administrator specifies the permission assignment for the related domainmodel, creates a role, creates a group, assigns a user to the group, and assigns a role to the group. (3 ): Permission:The user uses the roles assigned by the Administrator to use the corresponding system functions.

 

 

Module division: 1) object management module. This module is mainly responsible for managing available resources or resource instances in the system from the granularity. 2) permission management module. This module is mainly responsible for managing resource permissions. The administrator can manage resource permissions at a granularity. You can manage the permissions of created resource instances. 3) role management module. This module is mainly responsible for managing roles (including adding, deleting, and modifying) and managing permissions of roles (including granting and deleting permissions ); assign roles to users and groups. 4) user management module. This module is mainly responsible for managing users (including adding, deleting, and modifying), managing user roles (including adding and deleting), and managing user groups. 5) group management module. The Group maps to the organizational unit, which provides maintenance for the organizational unit of the Department (ADD, modify, and delete), maintenance for the members of the group, and management of the roles of the group.