RBAC permission Model--project actual combat

First, preface

permission A word to understand is the control of the resources, for Web applications is the control of the URL , about the permissions can not be polite to say that almost every system will contain, Just different systems on the application of the complexity of the program is not the same, now we are using the permissions model is basically based on RBAC to expand, we will today RBAC The permissions model is described below.  

Second, RBAC model

 

    RBAC ol The English abbreviation, meaning the role-based access control. RBAC thinks that authority authorization is actually the problem of who, what, how. In rbac model, who what how who --is the owner or principal of the permission (for example: user role what --is a resource or an object ( resource class )

RBAC in fact, it is an analytic model, mainly divided into: basic model RBAC0 (Core RBAC), Role layering model RBAC1 (hierarchal RBAC), role restriction model RBAC2 (Constraint RBAC) and unified Model RBAC3 (combines RBAC).

1 ) RBAC0

RBAC0 , it is The core of RBAC0, RBAC1, RBAC2, RBAC3 are successively in the RBAC0 on the expansion. RBAC0 defines the smallest set of elements that can form the RBAC control system,RBAC0 consists of four parts:

a, users (user)

b. Roles (role)

C, Sessions (Session)

D, license (Pem ission), where the license also includes "Operation" and "Control object" where a license is given to a role, not a user, when a role is assigned to a user, the user has the permissions that the role contains. A session is a dynamic concept in which a user must be able to set a role through a session, which is a mapping between the user and the active role.

in the figure, the user and the role are many-to-many relationships; roles and licenses are many-to-many relationships; a user is a pair of relationships; a conversation is a one-to-many relationship;

2 ) RBAC1

RBAC1 , which is a layered model of RBAC roles,RBAC1 based on RBAC0 , In the role of the introduction of the concept of inheritance, with inheritance then the role has a subordinate or hierarchical relationship

3 ) RBAC2

RBAC2, which is the constraint modelof RBAC ,RBAC2 is also established RBAC0 on the basis of the RBAC0 based on the concept of constraints, the main introduction of the static separation of duties SSD (Static separation of Duty) Separation of dynamic responsibilities DSD (Dynamic separation of Duty) .

SSDs are added to the user and role assignment phase, with the following constraints on users and Roles :

a , mutually exclusive roles: the same user can only select one of the two mutually exclusive roles

b , cardinality constraints: A user-owned role is limited, and a role-owned license is limited

C , prerequisite constraints: Users who want to get advanced roles must first have low-level roles

DSD is a constraint between a session and a role that can dynamically constrain a user-owned role, such as a user can have two roles, but only one role is activated at run time.

4 ) RBAC3

RBAC3 , it is RBAC1 and RBAC2 , so RBAC3 is a kind of model with both character stratification and constraint

The above is the RBAC model of four design ideas, now we use the permission model is based on the RBAC model based on their own business to combine and improve.

third, our permission model

First of all, we will explain our business, we do is the education industry University cloud platform, each school can be registered in our platform, after the registration can enjoy some basic services, of course, different levels of users enjoy the basic services are different, these basic services include new enrollment management, Basic system Management, examination system management, evaluation System Management module, each module is equivalent to a subsystem, each subsystem has its own function, each function also has its own related pages, and all the subsystems, pages and functions on the page buttons are required to manage our rights, Therefore, our authority management is relatively heavy task.

Let's take a look at the class diagram of our Rights Management module:

The core is also the RBAC model based on user, role, and license , but we extend the three individually:

User

No matter which user first it must belong to a department, the department is an administrative unit, and a department can also contain multiple users, so the relationship between the department and the user is 1 -to-many relationship;

First of all, why should have the concept of user groups, if there is a class of users to belong to a role, we give the user a role, repeated work particularly much, so we put such a number of users to classify, that is, user groups, so that we directly to the user group role, Reduce duplication of effort, so that the purpose is that all licenses owned by the user are the sum of the licenses owned by the user's personal role and the licenses owned by the user's user group to which they belong. A user can belong to more than one user group, a user group can also include multiple users, so the user and user groups are many-to-many relationships;

Role

A role is a set of licenses, a licensed carrier, a role can contain multiple users, and a user can also belong to multiple roles, so the relationship between roles and users is many-to-many. The same role can contain multiple user groups, one user group can also belong to multiple roles, so the role and user groups are many-to-many relationships;

License

License I generally call it a privilege, it includes control objects and operations, control objects are generally resources, including menus, pages, files and other resources, and operations generally include additions and deletions and other changes, the figure "System operation" is the operation, "menu Information" is the control object;

Menu information in each menu will be added to the deletion of the operation, so the menu information and system operation is a one-to-many relationship;

When we grant permissions to a role, the grant is the least granular permission, so we grant system operation permissions to certain roles. A role can have multiple system operations, one system operation can also belong to more than one role, so system operations and roles are many-to-many relationships.

Here we have the relationship between our permissions model is basically introduced, in the class diagram of the two classes between the many-to-many relationship in the database will appear in the third table, so let's look at the table in our database diagram:

Iv. Improvement

Now this permission model has been developed to put into use, of course, the current model is not necessarily the best, can only say that the scale of the current system is more appropriate, for the current permission model or there is a place to expand, in fact, the class diagram of the menu information, In the system we just rough the subsystem name, subsystem menu, Subsystem menu page elements, files, and so on all of these resources into a table is the menu information table, in the table we use the type to make a specific distinction, while using the subordinate relationship to manage the hierarchical relationship between them, However, there is a lot of redundancy in this table, and I think if you can improve it further, consider splitting the menu table by the menu type and then a table resource Relationship table to manage the relationships between these types of resources.

v. Summary

In this article, we introduce 4 kinds of design ideas of RBAC permission Model , and then we introduce the permission model of our own project in detail. At last, we put forward our own ideas for our current permission model. If you have any objection, please correct me.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

RBAC permission Model--project actual combat