references
1. MSDN documentation
2. MS Authorization and Profile Application Block Help Document
1 Overview
In application design, it is often necessary to control its behavior in the program based on different users. For example: administrators, managers, employees have differences in access levels in the program, and one user can play multiple roles. The ability of users to access protected resources or perform protected operations is called permissions, which can be expressed as "judging the logical expression of how to perform HOW on WHICH).
Existing permission certification is based primarily on two mechanisms: ACL (Access Control List) and role-based control.
ACL establishes an Access Control List (DACLS) for the Security Object. By comparing whether the user's permissions exist in the list, determine that the user can access the resource.
Role-based-based) divided the system by role. When the user is associated with a role, the permissions owned by the role will be automatically obtained.
In terms of enterprise applications, role-based control methods, due to reduced complexity of authorization management, easy to operate, with better prospects.
It is worth noting that permission is not a simple determination process. Permissions inspections often need to apply business logic. For example, the contract can only be deleted by its creator, and the same group can be modified, and the authorized user can view. Typically, it is called fine granular permissions related to instances of permission control objects, and only related to the object type is called coarse granular permissions.
Design goals
The permission system module provides basic architecture supporting a role-based authorization.
1. Authorization to users in the system
2. Support role inheritance
3. Multiple storage methods for support the permission system
4. Support business logic verification
5. Has good scalability and performance
2. Analysis
2.1. Workflow for permission systems
Overall, the operation of the permission system consists of the following procedures:
1 Permission system initialization
2 Permission System Received Users Access Request for Resources
3 Permission system Returns true or false according to the permissions of the user
4 Finally, the permission system releases its resources and destroys examples.
2.2. Permission system object
N resources
Resources is the protection object of the permission system. The resource can be an entity, such as files in the file system; or concept. In the application, resources are more divided into modules.
There is a nested relationship between resources. Such as: cash flow tables belong to financial statements.
The way of access to resources is called operation. Obviously, resources can have a variety of operations. Such as: Contract has different operations such as entry, view, modify, delete, execute, review, print.
There is an overlap relationship between operations, such as the contract reviewer, can of course view the contract.
The concept model is as follows:
N users and characters
The user is the access entity of the permission system. The role is the collective of a user with a certain type of permissions set. There is inheritance relationship between roles, such as finance supervisors, is also financial officers.
The concept model is as follows: It is worth noting that the permissions and roles do not have consistency. Such as: a user wants to have permissions outside its role; a role wants to mask a certain (some) user permissions belonging to its category.
The concept model extension is as follows:
1 Users can directly assign permission
2 The role is associated with a controlled list. The controlled list is that some users have access to the list of resources allowed in the role in the storage role.
2.3. Module of the permission system
N resource management
The controlled resources in the system are usually determined. If the resource changes, the common sense of the code is changed (including the resource allocation and verification section). Therefore, the resource management is relatively simple under the premise of the controlled resources in the system when the program is running.
a) Get list of all resources in the system
b) obtain resource information based on the resource (operation) identity.
n authority management
Permission management is a key part in the system, and the process determines that the permission is assigned to the entity object.
The functions of authority management are as follows:
a) Increase, delete, update the permissions of users or roles to resource access.
b) Get all permissions assigned to a user or role in the system.
c) Get the permissions of a user or role in the system to a certain resource (operation)
d) Add, delete role control list entries
It is worth noting that user permissions are the intersection of the role permissions of the user and the permissions they have given. Therefore, the role user flag is set in the permission object to distinguish.
n permission check
Permission check is the application section in the system. Permissions Check contains business logic checks.
1 Permission Check the function of the use rights manager.
2 The business logic checks two times. One after the permission check before the permission check. The business logic check before the authority check can be Ä directly return the result without having to check the permission check.
3. Permission system architecture
The permission system is designed as scalability. Use the Provider interface to use the interaction between permission models and data storage. Insert the entry insertion permission system by implementing a custom Provider.
The configuration file is mainly formatted in an XML file. The PROVIDER interface is defined as follows:
ELEMENT is an XML file element type
