Also bask in my RBAC system (1): overview

Introduction: there are already many RBAC problems in the garden.ArticleIn addition, this system also references the ideas and ideas of some of its friends and considers whether it is necessary to publish the system. However, although it is the same thing, because everyone's starting point and goal are different, they will not do the same thing. In addition, I have made some architectural designs, but it is not clear whether the implementation is appropriate. It is also a good thing to give advice to the brethren in the garden. I also thought about whether it was posted on the homepage. I feel that this article is worthy of everyone's words, regardless of the quality.

Body

I will not talk about the basic theory of RBAC here.
I came into contact with the concept of RBAC last year. Many things are not well understood, and I have been familiar with the permission management system of Windows Active Directory a few years ago, therefore, some concepts may differ from authentic RBAC concepts, but it should not have a big impact on the main idea of RBAC. If you think that some of the things I have joined are superfluous or you are not used to it, you are welcome to give your comments. I will make improvements based on the situation. Thank you.
In fact, I didn't have the idea of writing RBAC at the beginning, but after using Microsoft's membership, I feel very uncomfortable. I feel that it is not suitable for myself in terms of compatibility, usability, reusability, and other aspects. Just a few projects involved complicated user permission management functions. Therefore, at the beginning of the year, I decided to spend a few months dedicated to this project, that is, learning through this process, it also reduces the workload in the future.
Therefore, I wrote this article not to create an RBAC model, but to discuss it in theory, but to start from reality, write down the ideas I have made in this project along with the progress of the project, and discuss the theoretical and technical points encountered in this process.

Too much nonsense.
To use RBAC, you must first determine the requirements. At the beginning, we should consider the commonalities of these items based on several projects. Let's look at the parts that involve user management and permission verification, which are the things that need to be implemented by several projects and which are unique to a specific project, the requirements of RBAC are gradually established, and the functions to be implemented are determined.
At the beginning, I only want to build the project from the database model, and perform the BLL layer up. Other projects can use this BLL to process RBAC work, it is equivalent to sharing RBAC parts of several projects.
Later, I felt that if I only implemented this layer, the workload would be huge if I reused it later. Therefore, we decided to make the UI Layer of the background management part. This is equivalent to sharing the interfaces of several projects.
However, in the actual process, I feel that even the background management UI is made. Using this module in other projects is also troublesome. In addition, the project calls RBAC and calls modules in the project. When using RBAC projects, users still need to understand some internal operation methods. The coupling degree is too high and encapsulation is not implemented.
Later, I came up with another idea to see if I could make it into a framework. Although the level is limited, it is said that the framework is a little large and not necessarily perfect, but the goal can still be set to a higher level.
Since we want to build a framework, it is not to provide a database model and complete the relevant Code That's all. My idea is to allow users to create a database using scripts, copy the UI file to the project folder, and reference the DLL without any other configuration work, you can directly use this framework. When you program RBAC operations on your own, you only need one or two classes to complete all the work and hide all the details of the user.
Based on this idea, I started to build the project. Now I have established the following parts:
(1) BLL: business logic layer.
This layer is used to process business logic-related work. The content of this layer is only developed for members of RBAC projects and cannot be called externally.
(2) classfactory: class factory.
Currently, only data access layer objects can be created. Add new factories as needed.
(3) demo for winform: C/S Mode Interface Template
Windows Program Interface file and operation code. If you do not want to design the interface yourself, you can directly use this ready-made interface file.
(4) demo for webform: B/S Mode Interface Template
Provides interface files and operation code for web projects. If you do not want to design your own web interface, you can use it directly. Otherwise, you only need to create a new CSS file and replace the original CSS file to implement your own interface.
(5) idal: database access layer interface definition
Nothing to say
(6) model: entity class
Similarly
(7) Structured ledal: Oracle database access layer
Oracle Database is supported. This preparation should be put first, so Oracle programming is too uncomfortable.
(8) privilege config tools: Permission Configuration Tool
Windows program. When other projects use this framework, they need to generate their own permission files. This tool is used to do this.
(9) rbac manager: rabc management class
This is the external service part. Other projects only need to directly reference this DLL to perform various operations involving RBAC.
(10) sqlserverdal: SQL Server database access layer
Supports SQL Server databases. There is nothing to say.

As you can see, as an end user, if you use this framework in a project, all you need to do is to use the classes in RBAC manger namespace, you do not need to close the RBAC details.

After the project components are finished, let's introduce the database modeling.
Note: In order to ensure that everyone can see the images clearly, I have saved the images a little larger and the tables on the right cannot be seen. You have to pay for it and save it on the desktop.

Database Modeling diagram:

Purpose of each table
All Tables start with ksrbac to avoid duplicate names with other project tables.
(1) User Part
Ksrbac_users: basic user table. This table only stores a small amount of user information, which is used for user login, permission authentication, and other common work.
Ksrbac_usermembership: user permission table. This table is used to store the information about the permission system.
Ksrbac_userdetail: basic user information table. Used to Store Users' daily information. You only need to call this function when viewing user information.
In fact, the content of the three tables can be completely put into one table, but it feels that the content is divided into three tables, which will be clearer in programming. There may be unreasonable points here. I hope you can correct them.
(2) Permission Section
Ksrbac_resourcegroups: Resource Group. Group similar resources to facilitate management and support multi-level classification.
Ksrbac_resources: resource. Records specific resource objects.
Ksrbac_operations: operation. Record the specific operation method.
Ksrbac_privileges: Permission table. Create a "resource-operation" pair to customize permissions.
(3) Role
Ksrbac_roles: Role table. Store all roles.
Ksrbac_privilegeinroles: User table used to store Authentication-related information
Ksrbac_usersinroles: Role table of the user. This table is used to set the permissions of the role.
(4) Grouping
Ksrbac_groups: group table. Storage group information
Ksrbac_groupsingroups: Group Group table. Set the group to which the Group belongs.
Ksrbac_groupestates: Group status type Table.
Ksrbac_usersingroups: Group belongs to the user table. Set the user group.
Ksrbac_useringroupestates: Table of group user status types. Used for record The status of the user in the group.
(5) log Part
This part of the content has not been completed, because there is no progress in operations involving logs, so it is impossible to decide what needs to be done.
Ksrbac_userlog: user log. Used to record user operations

Users, permissions, and roles have no doubt about the tables. Some differences in understanding should also be caused by different design habits. I feel that I have different understandings in grouping. I have read some related articles and also involve grouping design, but these designs are far from functional. Some groups are associated with roles, which is equivalent to creating a rolegroups table, which plays a role of classification. Some groups are used as an organizational structure and then associated with users. Such groups play a role in classifying users. The group in this project is user-related, but role-independent. It implements the User Classification function. However, grouping is not only used to classify users, but also has an important function. However, it is hard to say that each time you write specific code, I will write it out after improvement.
there are still a lot of things you want to write, but at first it seems that the idea is not very clear, and there are some things you cannot write down. Do you have to say something about it? Just stop it. Let's take a look at your feedback and decide what to write. You are welcome to make a brick.
in the first article, no specific technical details are involved, but the project is ignored as a whole. If you have never used RBAC, you will surely feel that some of them are on Alibaba Cloud. I will explain it in detail in the future.