Discussion on the extension model based on RBAC
Abstract: Based on the famous RBAC model, combine how to make permission management issues, the role permission and its relationship between operation and operational objects have been analyzed, and an improved GRBAC model is proposed. This model is introduced Operating hierarchy number, rough permissions, fineness limit, etc. Rough permissions and fine permissions are processed separately by role hierarchy and group levels, and more refinement of permissions and users at the role level, and is roughened at the group level, which is convenient for system management users. And fine. The management strategy and method is also proposed.
Keywords: role-based access control; access control; rough permissions; fine permission; operation level; group control
1 Introduction
The role-based access control theory has been widely used in various fields, with the continuous change of their understanding, people's modification and enrichment, to meet the needs of different systems. The traditional RBAC model is based on role control, and the core idea can be briefly described as: all the users are allocated to their appropriate roles, and each role has specific permissions, and the permissions are assigned to user. Unlike many models that use user groups as access control units, the model emphasizes the concept of role. The main difference between the role and the familiar user group is that the group is generally treated as a collection, not a collection of permissions; the role is both a collection of user groups and a collection of permissions. The RBAC model is now expanded, introducing traditional user group control, but gives its new meaning, plus the operation hierarchical concept extension to get the GRBAC model.
2 extended GRBAC model
The design purpose of this model is to make permission management and control more convenient. Since the elements included in the real system development process are much less than the elements included in the role collection, the role of the traditional RBAC model will be used by the concept of the operation hierarchy and role. Relationship replacement, finally map the relationship to group control, more detailed relationship with the user at the role level, roughen the relationship and user relationship at the group level, forming a simpler and easy to understand Model of control.
2.1 Model definition
The Grbac model (Figure 1) is shown. First define a few new concepts:
Define 1: Group Collection (G): Defines a collection of roles with the same permissions or functions.
Note that group collection is related to the role, which is a collection of roles, not a collection of users. So a group element is permissions, it can also be understood as a collection of a particular operation object.
Definition 2: Operating Hierarchy (EI): Give all the operations in the operation set E give a layer, this hierarchy is used to perform group elements to correspond to a single operation object.
Definition 3: Roughness: Represents common privileges that only consider the category of the object, regardless of certain specific permissions outside the common privileges that it belongs to the category it belongs.
Definition 4: Sorting: Represents the instance level, that is, the permission to consider the specific object, of course, the fineness is a specific permission to consider after considering crude privileges.
Definition 5: Operation Hierarchy: Operation Hierarchy is a relationship of the elements in the operation set by operating hierarch (EI). The detailed description and design principles will be described in detail later.
Definition Use u Represents the user collection, R represents the character set, and the P represents the set of permissions, and e represents the set of operation, t means the operation object set, and S represents a collection of session.
Permission set P = E × T, the privilege set is the designer set of operative set E and operation object set t.
UA
U × r is a multi-to-many assignment of the user to the role, i.e., means that the user allocation process in Figure 1 is.
PA
P × r is a multi-to-many assignment that is permission to the role, that is, the authority allocation process in Figure 1. Figure 1 GRBAC model
2.2 Model Description
Suppose the operation set E = {R, W, E, D ...}, where R represents the read operation, W represents the write operation, and E shows the operation, D represents the delete operation. Now we correspond to the elements in the operation set E (as shown in Figure 2), which is to assign an operating level number to each of the elements in each operational set. According to the relationship of the level number, the operating level is small. The operation is placed under the bottom layer, and then the operating hierarchy is tested on top of the upper layer, and a hierarchy (as shown in Figure 3) is formed.
Due to the actual design system, the type of operations used for operation objects is not much, according to personal intuition, the "permission" of the operation can be protracted. For example, for R-read operation and W writing, it is just a single function "authority", and for E increase operation, it is certainly containing the function of W-write operation, because an increase in operation must write activities . So we give E increase the permissions of a R read operation. Similarly, the relationship between D operation and R, W, and E operation can be explained. Therefore, the same tree structure is presented (Figure 3) after design, and there is a "permission" inheritance relationship.
The following is a rule that the relationship between the assignment operation layer and the operation set element is given:
Rule 1: Have the operation hierarchy of the operation "permission" to be large, and the operation hierarchy allocated operation is small.
Rule 2: The operation corresponding to the operation level number, the operation of the large level number is the father of the operation corresponding to the small level number, and the operation corresponding to the small level number corresponds to the child.
Figure 2 Operating Hierarchy Assignment Figure 3 Operation Hierarchy
Since the operation set E and the operation object set T are formed by the Cartesian set, the permission set is completed by the relationship PA, and it is understood that for each specific operation object, for each of its There is a set of roles in a specific operation, and we map such a set of roles to the set gylatic gymn, and set a collection.
The relationship between them (Figure 4) is shown.
Figure 4 role, operational object, relationship between operation
There is a connection between group collections and role collections, and it is simple to describe elements in group collections consist of different roles, which have some operational permissions for a particular operation object. We did not define a certain number of operations of a particular operation object as a role. The purpose of this is to detail the relationship between the permissions and users at the role level, and the relationship of the user at the group hierarchy Roughness is convenient for system management users' roughness and fineness. Introduce management ideas later.
Through the description of Figure 4, we can also see that each operational object has a corresponding relationship with group elements and operational objects. For each operational object, it can include an operation defined in an operation set, and now, a single operation object and the operation thereon can now be manifested by the operating hierarchy defined in the previous. For operational objects, we can divide them into several parts according to some relationship, such as through departmental relationships, divide the operation set into operations of the operation objects of different departments, and then continue to make small collections according to other principles Divide. This can form a tree structure, a single node in the structure is an operation object, indicating the operation object as an operation hierarchy, then a single node in the forming structure diagram is expressed as a certain specific to the operation object. operating. Through Figure 4, it can be seen that a specific operation of the operation object can be imaged into a group element, so after this series of associations and changes, we can get (as shown in Figure 5). relation chart.
Systematic relationship diagram after Figure 5
3 management strategy
Through a series of associations, we established a systematic relationship after the association of (Figure 5). The management of system user rights should involve the management of concepts and fine permissions for the previously proposed. Under the GRBAC model, the management's policy is briefly described as: performs operation on the group when managing the privilege of the user; manipulating on the role when managing the user's fineness. As can be seen in Figure 5, after the operational hierarchy is mapped with the operation hierarchy map described in Figure 3, a single element has been mapped into group elements, and then the hierarchical relationship is also defined. When performing rudeness management, you can discuss the following:
(1) For the level or downgrade that enables "permissions" on its corresponding operation object, the table line can be a longitudinal change in Figure 5, and it is only necessary to change its hierarchy number.
(2) For the "permission" of the cross files to be enabled on the same level number, the table line can be a horizontal change in Figure 5, simply changing its layers and departments.
(3) For the interview with "permission" to enable the cross-file cross-"Permissions, asking the transverse and longitudinal changes, while changing the level number and operation objects and departments.
⑷ For adding permissions, copy group information to the appropriate location or use inheritance.
When doing fine-sighted management, you can perform the following discussion:
(1) For the user who reaches the degree of role, it can be changed to change the permissions corresponding to it.
(2) For users who only reach the degree of role want to increase permissions, create a new role, map their corresponding permissions, and add the corresponding group.
4 Conclusion
The extended GRBAC model is managed and controlled by introducing the concept of an operational level, combining the role access control principle and group control principle, which is compared to the traditional RBAC model, and some of the following advantages:
(1) Due to the reality development, the number of elements contained in the operation collection must not be a lot, so the introduction of operation hierarchical relationship is not complex, easy to control.
(2) Abandon the role hierarchy concept, make up by the mapping relationship between the operation level and the role. In a large system, since there are many characters, the role definition hierarchy is definitely not easy to define the level of operation, so it is easier, and the generated hierarchical relationship is finally combined with the group element, which is easy to control. .
(3) This model is more detailed in the role level, and the relationship between the user is roughened at the group hierarchy, which is convenient for the system management user's roughness and fine.
references
1 Hong Fan, He Xu Bin, Xu Zhiyong. Role-based access control. Small micro computer system, 2000.2
2 Denning D e, Wang Yumin translation. Password and data security. Beijing: National Defense Industry Press
3 Hongfan editor. "Discrete Mathematics Basic" Second Edition. Huazhong University of Science and Technology Press, 1995
4 Sandhu R s, Coyne E J, Feinstein H L.1996.Role-Based Access Control Models.ieee COMPUTER
5 David Ferraiolo and Richard Kuhn.Role-Based Access Controls.in 15thist-NCSC National Computer Security Confernce, Pages 554-563, Baltimore, MD, October 13-16 1992
