RBAC-Based Access Control and. netrbac Access Control in the. NET Environment

RBAC-Based Access Control and. netrbac Access Control in the. NET Environment

RBAC-Based Access Control in. NET Environment

Access Control of Application Based on RBAC model in. NET Environment

 

Abstract:This paper proposes an access control solution based on RBAC model based on the current trend of information system changes and the access to multiple resources. This solution uses the. NET environment as the platform and roles as the intermediary to connect users with resources and functions. When assigning roles to resources and functions, users with certain roles can access the resources authorized by this role, thus implementing role-based access control. This solution describes the access control operations and the superiority of Role-Based Access Control.

 

Keywords:RBAC;. NET; access control; role; Function

 

0. Introduction

Management information system is a complex interactive system. With the further application and development of computer technology, people have put forward higher requirements for the services it provides, each specific link may be vulnerable to security threats. It is very important to build a robust permission management system to ensure the security of the management information system. The permission management system is one of the most Reusable Modules in the management information system. All multi-user systems inevitably involve the same permission requirements. They must address security services such as entity identification, data confidentiality, data integrity, anti-Denial of Service, and access control. For example, a content publishing system used by a large website editing department has a series of functions such as content publishing, content review, and topic production, the Resource Access Management Service requires the system to control which resources the operator can access based on the Operation permissions set by the operator and determine how to operate the resources.

 

1. RBAC model

Role-Based Access Control (RBAC) is generally considered as an effective access control model, which is better than traditional independent access control (DAC) and Mandatory Access Control (MAC) with higher flexibility and better scalability.

 

1.1 brief introduction to RBAC model

As early as the 7O of 2O century, some people studied the issue of user access permission management in multi-user systems, that is, how to control users' access to resources, they call this Role-Based Access Control (Role-Based Access Control ). In 1996, RaviS. Sandhu and others proposed a general RBAC model. This model has three entities: User, role, and access permission (1 ).

 

Figure 1 Simplified RBAC model

The core idea is: the access permission of the protected function module is associated with the role, but only assigns different roles to the user. The user has no direct relationship with the question of the requested function module, to access a resource, the user must have a role that can access the resource. In the RBAC model, roles serve as bridges.

 

1.2 RBAC96 model definition

(1) RBAC96 model

This model is a RBAC96 model proposed by George Mason University RaviS. Sandhu. Its basic structure is 2:

Figure 2 RBAC96 model Diagram

The RBAC96 model has four different layers: The RBAC0 model specifies the minimum requirements required by any RBAC system; The RBAC1 Model adds the concept of Role Hierarchies on the basis of RBAC0, the hierarchical relationship between roles can be constructed based on the structure of organizational power and responsibility. The RBAC2 Model adds the concept of Contraints on the basis of RBAC0; the RBAC3 model is an integration of RBAC1 and RBAC2. It does not include the role level, but also the constraint relationship.

(2) RBAC0 Model

RBAC0 is the basic model. It contains three entities: User, role, and license.

Definition 1: basic concepts in the RBAC0 Model

① User: a subject that can independently access data in the computer system or other resources represented by data. It can be a person, a computer, or a person.

② Role: refers to the work or position in an organization or task. It represents a kind of qualifications, rights and responsibilities.

③ Permission: indicates the operation permit for accessing objects in a specific mode in the system.

④ User allocation: users are assigned corresponding roles based on their responsibilities and rights in the Organization. The relationship between users and roles is many-to-many. We use M: role → 2 user to indicate user allocation, and M [I] to indicate the user set authorized to role I.

⑤ License assignment: the role is associated with a group of operation licenses according to its responsibilities. Role and license are many-to-many relationships. We use P: role → 2permission to indicate license allocation, and P [I] to indicate the license set authorized to role I.

⑥ Session: indicates that the user interacts with the system. There is a one-to-many relationship between users and sessions.

7. Active role set (ARS): A session forms a ing between a user and multiple roles, that is, a session activates a subset of the role set granted to the user, this subset is the Active Role Set (ARS ).

(3) RBAC1 Model

The role hierarchy is introduced in the RBAC1 model to reflect the partial relationship between the Authority and responsibility distribution of an organization. Generally, the role hierarchy is described in partial order or greater than or equal. Role1 ≥ Role2 indicates that Role1 inherits all permissions of Role2. The partial order is self-inverse, transfer, and asymmetric.

Sometimes, for actual application needs, the scope of inter-role inheritance should be limited. If a role does not want others to obtain certain permissions, it can detach its own Private Roles ). The rights in a private role cannot be inherited. The private role mechanism can be used to shield certain permissions.

(4) RBAC2 Model

RBAC2 introduces a constraint set based on RBAC0 to determine whether various operations are acceptable. Constraints can be applied to all links in Figure 2. The following focuses on Role-related constraints.

① Base limit: At the same time, the number of roles that a user can own is limited. Similarly, the number of licenses for a role should be limited.

② Mutex roles: a single user can only be assigned to one mutex role set. at most one role or user can be assigned to multiple roles in a mutex role set, however, during a session, the user can activate one of the roles at most. The former is static mutex, and the constraint occurs in the user allocation phase. The latter is dynamic mutex, which occurs when the session selects ARS, that is, the runtime.

③ Prerequisite role: You can assign a role to a user only if the user already has another role. Likewise, you can assign a permission to this role only if the role already has another operation permission.

④ Time frequency limit: specifies the time and frequency that a specific role may use.

(5) RBAC3 Model

RBAC3 is the highest level model in RBAC96. It includes all the features of RBAC1 and rbac2. of course, RBAC0 is also indirectly included.

 

1.3. EHRBAC Model

In RBAC96, private roles are used to implement the issue that roles do not want to inherit all permissions. This method has many disadvantages: It separates the permissions of a logically unified role and belongs to the same role, so that many roles become incomplete roles and only exist for inheritance, there is no actual physical significance. The private role method increases the number of roles rapidly, which makes the role hierarchy very complex. To address this problem, many scholars have carried out research work in this area. EHRBAC (Extended Hierarchy Role Based Acces Control) is an improved hierarchical Role relationship model. This model discards the idea of a private role and follows the idea of modeling a real-world model. It defines the public and private permissions of the role and introduces general inheritance and extended inheritance mechanisms, A hierarchical Role Relationship Model with more complete functions and easier scalability is formed, which effectively solves problems arising from the use of private roles.

In the subsequent definitions, a user set is displayed in the u table, P indicates the license set, R indicates the role set, a user is displayed in the u table, p indicates an operation permit, and r indicates a role.

Define 2: Set CP: R → 2 P, CP (r) as a set of public permissions owned by role r.

Definition 3: make PP: R → 2 P, PP (r) the set of private permissions owned by role r.

Because permissions are divided into public and private permissions, two inheritance mechanisms are introduced: General inheritance and extended inheritance. Generally, inheritance can only inherit the public permissions of a role, but not the private permissions. The inherited public permissions are still public permissions.

Definition 4: Generally, inheritance defines a binary relationship between R and R. If NIAR × R is a set of general inheritance relationships, then (r1, r2) rr2. If r1 → r2, then for Ⅱ p, CP (r1), there is p, CP (r2 ).

Unlike General inheritance, extended inheritance not only inherits public permissions, but also private permissions. The inherited permission attributes remain unchanged.

Definition 5: extended inheritance defines a binary relationship between R and R. If EIAR × R is a set of extended inheritance relationships, then (r1, r2) rr2. If r1 · → r2, then for Ⅱ p, CP (r1), there is p, CP (r2), for Ⅱ p, PP (r1 ), there are p, PP (r2 ). In addition, the model also defines the following relationships.

Definition 6: link → + is defined as: If ra → + rb, there will be r1, r2 ,..., Rn ε R (where n> 0), so that ra → r1, r1 → r2 ,..., Rn → rb.

Definition 7: relational → * is defined as: If ra → * rb, then there is ra → rb or ra → + rb, which is called rb weak and generally inherits ra.

Definition 8: Relation → + is defined as: If ra → + rb, there will be r1, r2 ,..., Rn ε R (n> 0), so that ra → r1, r1 → r2 ,..., Rn → rb.

Definition 9: relational → * is defined as: If ra → * rb, then there is ra → rb or ra → + rb, which is called rb weak extension inheritance ra.

 

1.4. ARBAC97 Model

One of the most important parts of RBAC is its own management. The ARBAC97 model separates management from use (figure 3), and manages roles (AdministrativeRole) and administrative licenses (AdministrativePermission) is used to manage other roles and licenses. The RBAC96 model is a rule model. Its role and license are also called rule roles and rule licenses.

Figure 3 ARBAC97 Model

Definition 10: Management permission AP authorization changes to various components in the rule model, but rule license P is not allowed, that is, AP license P = Phi. The management license can only be granted to the management role AR, And the rule license can only be granted to the rule role R, so the AR between R = Phi.

The ARBAC97 management model consists of the following three parts:

(1) User-Role assigned URA97 (User Role Assignment 97 ). This topic discusses how to assign roles to users, including rule role assignment and management role assignment. A user can have both rule roles and management roles.

(2) license-Role Assignment PRA97 (Permission Role Assignment 97 ). This article mainly discusses the assignment and cancellation of licenses, including rule license assignment and Management license assignment. From the perspective of roles, users and licenses share the same features, so PRA97 and URA97 can correspond one to one.

(3) Role-RRA97 (Role Assignment 97 ). Each management role should be mapped to a subset of the Rule role. RRA97 mainly discusses the rule role scope managed by the management role.

 

1.5 comparison between RBAC model and traditional access model

Traditional Access Control technologies include Discretionary Access Control (DAC) and Mandatory Access Control (MAC ). DAC leaves the access decision to the Information owner, while MAC requires all users to abide by the rules established by the Administrator.

(1) independent access control (DAC)

DAC is a means of access control based on the visitor identity or working group. Access autonomy means that a visitor with a certain access permission can pass this access permission to other visitors (maybe not directly ).

(2) Mandatory Access Control (MAC)

MAC is based on the information sensitivity of the accessed object (such as expressed by tags) and the sensitive information that can be authorized to access the subject for permission control. MAC uses different security policies for different types of information and authorizes access to different types of data. It assigns a sensitive tag to each control subject and the accessed object, known as Securit Clearance and Security Classification ). The trust degree related to the access subject is specified, while the security classification specifies the trust degree of the access subject or program.

Obviously, role-based access control (RBAC) has two major features: 1. 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. 2. flexible support for information system security policies and great scalability to system changes.

 

2. RBAC implementation

2.1 System Structure

According to the RBAC model. NET Applications to access control, the first thing is to express the relationship between various object information (user, role, access permission) and object information, modeling, 4.

Figure 4 system RBAC Relationship Model

 

2.2 function Initialization

(1) function (Powers) is initialized to five:

Function ID	Function Name	Maximum permission
P1	News Classification	11110
P2	News content	11111
P3	Ad Classification	11110
P4	Advertisement content	11111
P5	Links	11111

Description: Maximum permission (up to 32 bits). Given the first digit indicates reading, the second digit indicates adding, the third digit indicates modifying, the fourth digit indicates deleting, and the fifth digit indicates recommending. In this example, only four permission codes are used. The maximum length of the data structure is 32 bits. The programming theory supports 56 bits (you need to change the database type to binary (4) the length of the field "permission") is 7. The data in this table is input by the developer. Cannot be modified after release

(2) The role data is initialized to four:

Role ID	Role name
R1	News editing
R2	Editor-in-Chief
R3	Ad Administrator
R4	Super Management

(3) Relationship between roles and functions (RolePowers)

Role ID	Function ID	Maximum permission
R1	P1	10000
R1	P2	11110
R2	P1	11110
R2	P2	10001
R3	P3	10000
R3	P4	11110
R4	P5	11111

Note: The permission cannot be greater than the maximum permission of each function.

(4) role inheritance (IRoles) Relationship: R2 inherits R1 (that is, R2 has the right to use all functions of R1)

Role ID	Parent role ID
R2	R1
R4	R1
R4	R2
R4	R3

(5) user (Users) data is initialized to 3 persons

User ID	User Name
U1	Xiaoming
U2	Datong
U3	Wuming

(6) Relationship between users and roles:

User ID	Role ID	Inheritance number
U1	R1	0
U2	R2	0
U2	R1	1
U3	R4	0
U3	R3	1
U3	R2	1
U3	R1	2

(7) Relationship between users and functions (UserPowers)

User ID	Function ID	Permission code
U1	P1	10000
U1	P2	11110
U2	P1	11110
U2	P2	11111
U3	P1	11110
U3	P2	11111
U3	P3	10000
U3	P4	11110
U3	P5	11111

User and function data are changed based on data changes in the preceding tables. The permission code is the permission code corresponding to user u and function p after overlapping function p.

(8) Other functions

Menu (Menus) Association functions can be classified according to the actual situation:. Net Web and. Net WinForm. The same function corresponds to different menus of the two systems.

The user menu (UserMenus) is similar to the user and function (UserPowers), and the system changes according to the corresponding permissions of the personnel.

 

2.3 system running mode

The system is built in the. Net environment and is divided into two versions: B/S and C/S. The same business logic is used. The only difference is the display mode. Same running mode:

(1) The user must pass identity authentication when logging on. This process is completed by the authentication center. After passing identity authentication, users will get all their menus and start sessions.

(2) The system builds the obtained menu, and B/S mainly accesses the menu through the page address. C/S stores the form, control namespace, and Class Library name, use reflection technology to create.

(3) Access the corresponding page and determine the functional permissions at the page level, such as addition, modification, deletion, review, and other fine-grained operations.

(4) The user completes the LOGOUT system and ends the session.

The system can be used as the basic implementation of permission control for other information management systems. Other systems can be developed by the system, so that user permission allocation, revocation, and other related transactions are not considered.

 

3. Conclusion

RBAC is a new access control technology. It introduces the role intermediary to implement logical separation between users and access permits, greatly facilitating permission management. RBAC has attracted a wide range of attention in the field of research, users and software vendors. It is considered to be a more common access control technology than traditional DAC and MAC.

This article provides related solutions for the traditional RBAC 96 model in the role inheritance relationship and authorization allocation. However, in the actual operation process, there is a certain relationship between tasks, such as the relationship between exclusion and dependency. In this article, no solutions have been provided for this aspect. In our future work, we may make some efforts in this regard.

 

References:

[1] Jiang Min, Wu chengrong, Zhang shiyong. Database Access Control Model Analysis [J]. Computer Engineering and application, 2002, (13): 183-185.

[2] He haiyun, Zhang Chun, Zhao zhansheng. Role-Based Access Control Model Analysis [J]. Computer Engineering, 1999, (8): 39-44.

[3] Shi jingchao, Sun weixiang, Xu manwu. Role-Based Access Control and Its Implementation [J]. Computer Application Research, (6): 13-15.

[4] Zhong Hua, Feng Yulin, Jiang Hongan. expanded the role hierarchy model and its application [J]. Journal of software, 779 (6): 784.

[5] Li Mengke, Yu xiangxuan. Role-Based Access Control Technology and Application [J]. Computer Application Research, (10): 44-47.

[6] Zhang dajiang, Qian hualin. RBAC model implemented using digital certificates [J]. Small computer system, 936 (8): 939.

[7] Yan Yaping, Li weiqin, and Liu huaiyu. research and Implementation of Role-based fine-grained access control system I-J]. journal of Beijing University of Aeronautics and Astronautics, 2001, 178 (2): 181.

[8] Huang Yimin, Yang zijiang, Ping Linglong, and so on. implementation of Role-Based Access Control in the security management system [J]. journal of Zhejiang University (engineering edition), 2004, 413 (4): 4 0 8.

[9] He bin, Gu jian. permission management system based on role access control [J]. Computer Engineering (additional publication), 326: 328.

[10] Zhou wenfeng, Yu junkao, He jixiang. Design and Implementation of a permission management system based on RBAC model [J]. Micro-Computer letter (15): 35-36.

[11] Xia zhixiong, Zhang Shuguang. Application of RBAC in Web-based management information system [J]. Computer Application Research, 2004, (7): 198 ~ 199.