SlickSafe. NET open source permission Framework Development Guide, slicksafe.net Open Source

SlickSafe. NET open source permission Framework Development Guide, slicksafe.net Open Source

This article is applicable to users who want to quickly build a permission system, especially those who want to have a well-defined permission model. The system solution is based on role-based access control (RBAC) the permission access model based on the policy implements the background permission verification logic and front-end permission data verification functions.

1. Permission Access Model

1). Basic concepts of permission access control

• Role:Is a collection of users, indicating a collection of users of the same type, can have the same function operations. For example, "department manager" indicates a set of users of various department managers in the company. Generally, they have the same permissions.
• User:A software user logging on to the system for operation, identified by the user name or login name. Each user is assigned an operation list.
• Resource:It refers to the general term for each element set of the entire software system. Common types include system, module, menu, form, button, field and method.
• Permission:Terminology of whether a role or user has the right to operate on a resource item.
• Authorization:An authorization operation on a role or user indicates whether the role or user has the permission to perform operations on a resource item.
• License type:Either allow or deny. "Allow" indicates that you have the permission, and "deny" indicates that you do not have the permission.

 

2) Permission Calculation Model

A) two types of permissions: inheritance and self-owned

• Inherited permissions:A user may belong to multiple roles. In this way, the permissions of multiple roles can be inherited, through Role authorization, you can easily implement batch authorization of user permissions.
• Self-owned permissions:Permissions directly authorized by users are not inherited permissions. Generally, the Administrator grants special permissions to a resource.

B) Two Types of permission licenses: Allow and deny

• Allowed:The value of permission is allow, indicating that the user has the permission to operate on a resource.
• Reject:If the permission is denied, the user does not have the permission to operate a resource.

C) Permission Calculation

• Self-owned permissions U inherited permissions:By default, the user obtains the inherited permission. if the user has a value for his/her own permission, the user takes the permission first;
• Deny permissions U allow permissions:If a user has both the allow and deny permissions for a resource item, the deny permission is greater than the permitted permission;

Example:

 

In the above authorization process, the user inherits and rejects permissions to participate in calculation. For the "add" item of resource data: it has "allow" operations from its own permissions and "deny" operations from inherited permissions. After the permission calculation, the user has the "allow" permission for the "add" item of the resource data.

 

3) Two authorization Methods: Role authorization and user authorization coexist.

Role authorization:The Administrator uses the role to grant permissions to resource items. This authorization method is preferred by the Administrator and is used to grant full resource permissions in advance;

User authorization:The Administrator completes the permission authorization for resource items through the user. This is an operation by the Administrator to fine-tune the user permissions. Generally, the Administrator queries the permission list based on the user, and then operates (allow and deny) based on the permission) to authorize resources.

2. Database Design

1). Basic data table

 

 

2). Stored Procedure Implementation Logic

Read the role permission list, read the user permission list, and save Role authorization and save user authorization have corresponding stored procedures. Permission calculation is required during authorization.

 

3. Front-End Interface operation instructions

1) Role authorization

The role list is on the left. When a role record is selected, the permission data list on the right appears. Then, you can authorize the resource list data. After each role record is authorized, you need to save it. When you want to clear the permission records of a role, clear the check box of the permission list for the role's resource items and save the records.

2) user authorization

The user list is displayed on the left. When a user record is selected, the user's permission list is displayed. Then, you can grant permissions and save them. User permission authorization requires that you have the permissions inherited from the role and your own permissions. You need to understand the permission calculation model during authorization.

 

 

3) Main Interface display

After a user logs on to the system, the left-side navigation menu displays the menu items based on the user's resource list data. When you record the data on a specific page, the operation button on the top of the page is displayed based on whether the user has the permission to allow the operation. The yellow button indicates that the user does not have this function.

 

 

4. Advantages of the permission development framework

1). Based on the SlickOne rapid development framework, code reuse is high;

2). The well-defined permission model successfully solves the problems of user permission inheritance and self-owned calculation;

3). The programming framework of the front-end interface permission control function allows developers to easily implement the principle of data and function separation, facilitating secondary development and function improvement.

 

5. Commercial authorization and technical support

The SlickSafe open-source permission Development Framework provides project business authorization, online product training, and technical support. You are welcome to consult and learn more.

 

Contact info:

QQ: 47743901 (crossing the river)

EMail: sales@ruochisoft.com

 

6. Exchange and Suggestions

The open-source permission development framework allows users to quickly build a permission model for enterprise software, and keeps improving and improving programming code practices, we hope that users or developers who need it will continue to promote the project.

Open Source Project address:

Http://github.com/besley/slicksafe

 

QQ chat group:

331928998

 

DEMO:

Http://demo.slickflow.com/ssweb/

User Password: admin/123456, jack/123456