Implementation of RBAC-based permission management system-classic

0

In many practical applications, users are not only required to register and log on, but also have different operation permissions on resources for different categories of users. At present, the permission management system is also one of the modules with the highest repetition rate. In enterprises, different application systems have an independent permission management system. Each permission management system only meets the permission management needs of its own system. This inconsistency may have the following drawbacks:

(1) The system administrator must maintain multiple permission management systems;

(2) user management, organization and other data duplication maintenance, data consistency and integrity are not guaranteed;

(3) Different permission management systems have different designs, different concepts, and different technologies. The integration between permission management systems has problems, making it very difficult to implement Single-point logon, it also brings difficulties for enterprises to build enterprise portals.

Adopts unified security management design ideas, standardized design, and advanced technical architecture system, build a general, complete, secure, easy-to-manage, portable, and scalable permission management system that truly becomes the core of permission control, it is necessary to play an important role in maintaining system security.

This article introduces the design and implementation of a role-based access control (RBAC) model. NFT Framework 2.0 architecture technology implementation, and discusses how the application system can access and control permissions.

1. RBAC Basic Ideas

There are generally three access control policies in the enterprise environment: autonomous access control method, forced access control method, and threat-Based Access Control Method (RBAC ). The autonomy is too weak and the force is too strong. The two work the most and are not easy to manage. The role-based access control method is currently recognized as an effective solution to centralized resource access control for large enterprises. The two most important features are: (1) reducing the complexity of authorization management and management overhead; (2) flexibly supporting enterprise security policies, it also provides great scalability for enterprise changes.

The national institute of standards and technology (NIST) Standard RBAC model consists of four component models, the four component models are the basic model RBAC0 (core RBAC), The Role classification model RBAC1 (hierarchal RBAC), and the role restriction model RBAC2 (constraint RBAC) and the unified model RBAC3 (combines RBAC ). RBAC0 Model 1 is shown.

　　

(1) RBAC0 defines the smallest element set that can constitute an RBAC control system. RBAC contains five basic data elements: User users (USERS), role roles (ROLES), target objects (OBS), Operation operations (OPS), and permission permissions (PRMS, permissions are granted to a role rather than a user. When a role is assigned to a user, the user has the permissions contained in the role. Session sessions is the ing between the user and the activated role set. The difference between RBAC0 and traditional access control is that adding an indirect layer brings flexibility. RBAC1, RBAC2, and RBAC3 are successively extended on RBAC0.

(2) RBAC1 introduces the inheritance relationships between roles. The Inheritance relationships between roles can be divided into general inheritance relationships and restricted inheritance relationships. Generally, only the absolute Partial Order of the role inheritance relationship is required, and multiple inheritance between roles is allowed. The restricted inheritance relationship further requires that the role inheritance relationship is a tree structure.

(3) The responsibility separation relationship is added to the RBAC2 model. RBAC2 constraints specify the mandatory rules to be followed when a role is granted or a role is granted to a user and when a user activates a role at a certain time. Separation of duties includes static and dynamic separation of responsibilities. The relationship between constraints and user-role-Permission determines the access permission of users in the RBAC2 model.

(4) RBAC3 contains RBAC1 and RBAC2. It not only provides the inheritance relationship between roles, but also provides the responsibility separation relationship.

In fact, RBAC regards permission authorization as a problem of Who, What, and How. In the RBAC model, who, what, and how constitute three access permissions, namely, "Who performs How operations on What (Which ". We will discuss this in detail in the following description.

 

2. NET Framework 2.0 Architecture Design

Use the. NET Framework 2.0 enterprise platform architecture to build a permission management system. NET Framework 2.0 integrates advanced software architecture ideas and features multi-layer Distributed Application Model, component-based and reusable components, unified and complete model, and flexible transaction processing control. When necessary, you can seamlessly connect to the Active Directory of Windows Server 2003 and manage user accounts directly through Active Directory.

The system is logically divided into four layers: presentation layer, business layer, data access layer, and data layer.

(1) interaction between the principal host in the performance layer. Allows the system administrator to access the service through a Web browser.
(2) The business layer provides business services, including business data and business logic, and centralizes system business processing.
(3) The data access layer is mainly responsible for data access, such as adding, modifying, deleting, and searching data.
(4) The data layer is mainly responsible for data storage, organization, and management. The data layer uses SQL Server 2000 or SQL Server 2005.

3. Core Object Model Design

Create a database model of the permission management system based on the permission Design Concept of the RBAC model, as shown in figure 2.

 

 

 

Create the core object model of the permission management system based on the permission Design Concept of the RBAC model, as shown in figure 3.

　　

RBAC solves the Who, What, and How problems. Use Figure 3 to provide a detailed description:

Who: The owner or subject of the permission (User, Group, Role, Actor ).

What: the object or Resource to which the permission is granted. The Resource has a hierarchical and inclusive relationship. For example, a webpage is a resource, and objects such as buttons and text boxes on a webpage are also resources. It is a subnode of a webpage node. If buttons can be accessed, the webpage must be accessible. The resource should be in a tree structure.

How: specific permissions (Privilege, forward authorization and negative authorization). This permission is bound to a specific object. For example, the publishing permission of the news in the instructor evaluation system 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 ).

Operator: operation. Indicates How to operate on What. That is, the set of Privilege resources;

Role: a Role, a set of a certain number of permissions, 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 of permission assignment are directly mapped to the organizational relationship. 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 ParentGroup of the Group during creation. 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 ".

User: a pure User, isolated from permissions, can only be associated with the corresponding permissions through Role.

The main relationships in this model include resource allocation (resource assignment), allocation of role permissions (privi-lege assignment), and allocation of user group roles (group as-signment) description:

(1) Allocate Resource Access RA: map the association between resources and operations.
(2) Assign role permission PA: ing the association between operations and roles.
(3) assign a user group role GA: map the association between user groups and roles. The operation mode of the permission management system is divided into the following three steps:

(1) create resources and permissions: When you create a resource (Re-source) instance, specify the relevant permissions and assign permissions. For example, only the creator of the student evaluation can have the modification permission, and the same Group can only have the viewing permission.

(2) Assign permissions: the system administrator assigns the permissions of related resources (Re-source), creates a Role, creates a Group, assigns permissions to the Role, and assigns users to the Group, assign a Role to a Group.

(3) permission: the User uses the role assigned by the Administrator to use the corresponding system functions.

4. Permission Access Mechanism

Permission management system server: provides centralized permission management services and provides user identification, user information, user group information, and permission relationship table calculation, as shown in figure 4.

　　

The system calculates the minimum permissions of a user based on the associations between users, user groups, roles, operations, access methods, and resource objects. In the business logic layer, use the SecuirtyManager. GetPower () method to implement this service. The Proxy mode is used to centrally control the permission calculation service to be accessed from the application system, and return the permission relationship table, that is, the Binary Group {ResouceId, OperationId }.

In the presentation layer, you can access the permission management system through the access capability table CL and access control table ACL. The following uses the. NET Framework-based instructor evaluation system as an example to describe the access process:

(1) form-based verification is used first. Considering that the entity to be identified is a user, ACL-based access is adopted. When a user logs on, the user identification service of the permission management system is called. If the verification succeeds, the permission calculation service is called, and the permission relationship table is returned, which is stored in the global Session of the logged on user as HashTable; if there is no global Session or expiration, it will be directed to the logon page and re-obtain the permission.

(2) Direct URL resources use CL-based access control. If you directly enter a URL address to access the page, you can use either of the following methods to control access: 1. read CL through permission labels for control; 2. the permission control mode is used for page manned judgment. If you do not have the permission, the system redirects to the logon page.

5. Permission control mechanism

Because the permission control of the application system is related to a specific technical environment. the instructor Evaluation System of the NET Framework 2.0 architecture is used as an example to describe that the main display component of the system is the aspx page, which is implemented by the tag and permission control components.

(1) Permission ID: Use the page tag to identify all access control objects on the page.

(2) Permission control: When an application system user logs on to the system and obtains the permission relationship table from permission management, on the one hand, the permission tag control page is displayed; on the other hand, use the permission control component to control permissions in the business logic, especially the permission control of the object instance that is closely linked with the business logic.

6. Permission Data Storage Mechanism

Permission management uses relational databases SQL Server 2005 or SQL Server to store user information, user group information, roles, operations, permissions, and other information.

7 conclusion

This article describes the technical solution for implementing a permission management system based on RBAC. This permission management system has been successfully applied to the design and development practices of the instructor evaluation system and is well integrated with the instructor evaluation system. Practices show that permission management systems based on RBAC have the following advantages: the changes between roles and permissions are much slower than those between roles and users, this reduces the complexity of authorization management and management overhead. It also flexibly supports the security policies of application systems and greatly scales the changes of application systems, permission allocation is intuitive, easy to understand, and easy to use. Hierarchical permissions are suitable for hierarchical user-level forms and are highly reusable.