RBAC (Role-Based Access Control)

Role-Based Access Control (Role-Based Access Control) has been widely concerned as a promising alternative to traditional access control (autonomous access and forced access. In RBAC, permissions are associated with roles. You can obtain permissions of these roles by becoming a member of an appropriate role. This greatly simplifies permission management. In an organization, roles are created to complete various tasks. Users are assigned roles based on their responsibilities and qualifications, you can easily assign a role to another role. Roles can be assigned new permissions based on the new requirements and the merger of the system. permissions can also be revoked from a role as needed. The relationship between roles and roles can be established to cover a wider range of objective situations. Directory

1 Overview

2 Basic Concepts

3. Model

? RBAC96 model

? Arbac97 Model

? Drbac

4. License Configuration

5 RBAC model features

1. Edit RBAC to support three well-known security principles: Minimum permission principle, responsibility separation principle, and data abstraction principle. (1) the principle of least privilege is supported by RBAC because RBAC can configure its role as the minimum permission set required to complete the task. (2) The responsibility separation principle can be embodied by calling mutually independent and mutually exclusive roles to jointly complete sensitive tasks. For example, a clerk and a financial administrator are required to participate in the same posting. (3) data abstraction can be reflected through permission abstraction, such as abstract permissions such as borrowing and deposit for financial operations, without the typical read, write, and execute permissions provided by the operating system. However, these principles can only be embodied through detailed configuration of RBAC components. RBAC has many components (bucu), which makes RBAC management multi-faceted. In particular, we need to separate these questions to discuss: user and role assignment; Role and permission assignment; Role and role assignment for defining role inheritance. All these activities require that users and permissions be linked. However, in many cases, they are best performed by different administrators or management roles. Assigning permissions to a role is the responsibility of a typical application manager. In the banking application, the loan and deposit operation permissions are assigned to the cashier role, and the approval loan operation permissions are assigned to the manager role. Assigning specific personnel to the corresponding cashier and manager roles is the scope of personnel management. The assignment of roles includes the assignment of users and roles, and the assignment of roles and permissions. In general, the relationship between roles reflects a wider range of policies. 2. Edit basic concepts RBAC considers that permission authorization is actually a problem of who, what, and how. In the RBAC model, who, what, and how constitute three tuples of access permissions, that is, "who performs how operations on what (which ". WHO: The owner or subject of the permission (such as principal, user, group, role, actor, etc.) What: the object or resource (resource, class) for which the permission is applied ). How: specific permissions (privilege, positive authorization and negative authorization ). Operator: operation. Indicates how to operate on what. That is, privilege + resourcerole: a set of roles with a certain number of permissions. The unit and carrier of permission allocation, which aims to isolate the logical relationship between user and privilege. GROUP: user group, and the unit and carrier of permission allocation. Permissions are assigned to the Group Regardless of specific users. A group can contain groups (to inherit permissions) or users. users in a group can inherit the permissions of a group. The relationship between user and group is many-to-many. Groups can be hierarchical to meet the requirements of permission control at different levels. RBAC focuses on the relationship between role and user and permission. The relationship is called the user assignment (UA) and permission assignment (Pa). The relationship between the left and right sides is the same-to-minus relationship. That is, the user can have multiple role, and the role can contain multiple users. All RDBMS users know that the N: M relationship requires an intermediate table to store the relationship between the two tables. The UA and PA are equivalent to the intermediate table. In fact, the whole RBAC is based on the relational model. Session is an obscure element in RBAC. In terms of standards, each session is a ing, and one user is mapped to multiple role. When a user activates a subset of all his roles, a session is created. Each session is associated with a single user, and each user can be associated with one or more sessions. in RBAC systems, a user is actually playing a role and can replace the user with an actor. This idea comes from the actor-role mode in business modeling with UML. Given that multiple people can have the same permissions, RBAC introduces the concept of group. Group is also considered as an actor. The concept of user is like a person. The group and gbac (group-based Access Control) are different. Gbac is mostly used in the operating system. The Group is directly associated with the permission. In fact, RBAC also draws on some gbac concepts. Both group and user are related to the organizational unit, but not the organizational unit. The two are conceptually different. An organizational unit is an abstract model of a physical company structure, including departments, persons, and positions. The permission model describes abstract concepts. Generally, the organizational structure is modeled using the Party or responsibility mode of Martin Fowler. The relationship between person and user in party mode is that each person can correspond to a user, but not all users have corresponding persons. The department or organization in the Party can correspond to the group. Otherwise, the group does not necessarily correspond to an actual organization. For example, you can have a group named "deputy manager". Many people share the same responsibilities. The introduction of the group concept is not only used to solve the problem of the same roles of multiple people, but also used to solve another authorization problem of the Organization: for example, I hope everyone in department a can read the news from department. With such a group corresponding to Department A, you can directly authorize this group. [1] 3. Edit the RBAC96 model 1. Basic Model rbac0 ModelDefinition: The rbac0 model is determined by the following description: U, R, P, and s indicate the user set, role set, permission set, and session set. Pa P × R indicates the multiple-to-multiple assignment relationship between the permission and the role. Ua u × R indicates the many-to-many relationship between the user and the role. User: S → u ing function from each session Si to a single user (SI) (constants represent the Session Declaration cycle ). Role: S → 2 ing function from each session Si to the role subset roles (SI) {r | user (Si, R') ε UA} (can change with time, session Si has the permission to ur in roles (SI) {p | (p, R') in PA }. When using the rbac0 model, each permission and each user should be assigned to at least one role. It is possible that the permissions assigned to the two roles are identical, but they are still completely independent. The same applies to users. A role can be considered as a semantic structure as the basis for formalizing access control policies. Rbac0 does not interpret the permission, because its exact meaning can only be determined by the implementation and is related to the system. The permission in rbac0 can only be applied to data and resource objects, but cannot be applied to components of the model. Modifying the permissions of the set U, R, P, and relationship Pa and UA is called management permissions. The Management Model of RBAC is described later. Therefore, in rbac0, it is assumed that only the security administrator can modify these components. A session is controlled by a single user. In the model, you can create a session and select some subsets to activate the user role. The role activation in a session is determined by the user, and the termination of the session is also initiated by the user. Rbac0 does not allow one session to create another. A session can only be created by the user. 2. Role grading model rbac1Definition: rbac1 is determined by the following content: U, R, P, and s indicate the user set, role set, permission set, and session set. Pa P × R indicates the multiple-to-multiple assignment relationship between the permission and the role. Ua u × R indicates the many-to-many relationship between the user and the role. RH r×r is a partial relationship to R. It is called a role level or a dominant relationship and can also be expressed by ≥0. User: S → u ing function from each session Si to a single user (SI) (constants represent the Session Declaration cycle ). Role: S → 2 each session Si to role subset roles (SI) {r | (R' ≥r) [user (Si, R ') extends UA]} (can change over time) ing function. Session Si has permission ur ε roles (SI) {p | (r'' ≤ r) [(p, r'') ε PA]}. 3, Restricted model rbac2The rbac2 model is formed after limitations are added to the rbac0 model. It is not compatible with rbac1. Rbac2 is defined as follows: Definition:In addition to adding some restrictions to rbac0, rbac2 does not change from rbac0. These restrictions are used to determine whether the values of each component in rbac0 are acceptable, only acceptable values are allowed. The limitations introduced in rbac2 can be applied to all the relationships and components in the rbac0 model. When a basic restriction in rbac2 is set, the role is mutually exclusive. A mutex role is a two-role with one-to-one permission. For such roles, a user can only be assigned one of the roles in a certain activity, and cannot obtain the right to use both roles at the same time. For example, in an audit activity, a role cannot be assigned to both the accounting role and the auditor role. For example, in a company, the roles of the manager and the deputy manager are mutually exclusive. Contract or check can only be signed by the manager, but cannot be signed by the Deputy Manager. In the rbac2 model created for the company, a user cannot have both the manager and deputy manager roles. The mutual exclusion restrictions of model aggregation can support the implementation of the separation of duties and responsibilities principle. In general, mutex can control whether the user's member relationships in different role combinations are acceptable. For example, a user can be both a programmer of Project A, a tester of Project B, and a reviewer of Project C, but he cannot be the three roles of the same project at the same time. The rbac2 model can limit this situation. Another example of user assignment restriction is a role's maximum number of members, which is called the role's base limit. For example, the highest leader of a unit can only be one person, and the number of middle-level cadres is also limited. Once the number of users assigned to these roles exceeds the role base limit, it will no longer accept new users. It is difficult to limit the minimum base of a role. For example, if the minimum number of users occupying a role is specified, the problem is how the system can know at any time that some of these users have not disappeared. If so, what should the system do. When assigning a Role A to a user, in some cases, the user must be a member of Role B, and Role B becomes a prerequisite role for role. The prerequisiteroles concept comes from capabilities and adaptability. Absolute restrictions on prerequisites are a prerequisite. A common example is that an associate professor in mathematics should be promoted from a lecturer in mathematics, who is a prerequisite for being an associate professor. However, in the actual system, preconditions between incompatible roles also occur. In graph ap08-03, you can limit that only Members of this project are eligible for the role of a programmer, typically at a lower level than the new role in a system. However, in some cases, it is required that a user can assume another role a only when the user is not a special role. For example, the members of this research group should not be members of the results appraisal committee of this project. Such restrictions can also be applied to licensing. Users and roles are associated with sessions. Therefore, you can restrict sessions. For example, a user can be assigned to two roles, but the user cannot be activated in both roles at the same time. In addition, you can also limit the number of sessions that a user can activate at the same time. Correspondingly, you can also limit the number of permissions allocated to sessions activated by the user. The inheritance concept mentioned above can also be considered as a limitation. Permissions assigned to lower-level roles must also be assigned to all upper-level roles of the role. Or equivalent. A user assigned to a higher-level role must be assigned to all lower-level roles of the role. Therefore, the rbac1 model is redundant and contained in rbac2. However, the rbac1 model is concise, and the concept can be clearer by replacing the limitation with inheritance. You can use functions to implement restrictions. When you specify a role for the user or assign permissions to the role, you can call these functions for checks. Based on the results returned by the function, you can determine whether the allocation meets the restrictions, it is usually implemented only for some simple restrictions that can be effectively checked and those that are common, because these restrictions can be maintained for a long time. The validity of the restriction mechanism in the model is based on that each user has only unique identifiers. If an actual system supports multiple identifiers, the restriction will become invalid. Similarly, if the same operation can have more than two permissions, the RBAC system cannot implement enhanced basic restrictions and separation of responsibilities and restrictions. Therefore, the user and its identifier are required to have a one-to-one correspondence between the license and the corresponding operation. 4. Unified Model rbac3Rbac3 combines rbac1 and rbac2 to provide the classification and Inheritance of roles. However, combining these two concepts also causes some new problems. The restriction can also be applied to the role level itself. Because the level relationship between roles satisfies the partial order relationship, this restriction is essential for the model and may affect this partial order relationship. For example, additional restrictions may limit the number of subordinate roles that a given role should have. Two or more roles may be restricted to non-public upper-level or lower-level roles. Restrictions of these types are useful when the power of the conceptual role level has been decentralized, but the security supervisor wants to limit all methods that allow these changes. There is also a sensitive mutual influence between the limit and the role level. In a graph ap08-03 environment, a project member is not allowed to be both a programmer and a tester, but the location of the Project Administrator is clearly in violation of this restriction. In some cases, it is acceptable for a high-level role to violate this restriction, but in other cases, this violation is not allowed. From a strict perspective, the model rules should not be allowed in some cases, but in other cases. A similar situation occurs in the limit on the base. If one user is limited to multiple roles, can one assignment to the tester in the figure not be subject to this restriction? In other words, can the base limit be used only for direct members or inherited members? The concept of private roles can indicate that these restrictions are useful. Similarly in the graph ap08-03 environment, the tester, programmer and the Project Administrator three roles can be described as mutually exclusive, they are at the same level, there is no common superior role, therefore, the administrator role does not violate the mutex restriction. Generally, there is no public upper-level role between a private role and other roles. Because they are the largest elements of this level, the mutex between private roles can be defined without conflict. The same part of these private roles can be described as the maximum technical limit with 0 members. In this way, the tester must be assigned to the tester role, which serves as a tool to share the permission with the administrator role. Arbac97 is a role-based role management model. It consists of three parts: ura97: user-role assignment. This component involves the management of user-assign relationship UA, which associates users with roles. The permission to modify the relationship is controlled by the management role. In this way, the Members in the management role have the right to manage the members in the formal role. It is assumed that a user is assigned a management role other than ura97 and is completed by a security officer. Pra97: permission-role assignment. This component involves role-Permission assignment and revocation. From the perspective of roles, users and permissions have similar characteristics. They are all real entities associated with roles. Therefore, pra97 can be considered a dual component of ura97. Rra97: Role-role assignment. Roles are classified to facilitate role management. This component involves three types of roles:

1. Abilities role: a Member role that uses permissions and other capabilities.
2. Group roles-only roles of users and other groups.
3. Up-role-indicates the role of the user and the permission. Such roles have no restrictions on its members. Members can enable the user, role, permission, capability, group, or other up-roles.

The main reason for the difference between these three models is that different management models can be used to establish relationships between different types of roles. The motivation for differentiation is first to consider the ability. The ability is a set of permissions. You can assign all the permissions in the set as a unit to a role. Similarly, a group is a collection of users. You can assign all the permissions in the collection to a role as a unit. Both groups and capability roles can be classified. In an up-role, whether a capability is a member is determined by whether the up-role is able to control the capability. If yes, otherwise no. Conversely, if an up-role is dominated by a group role, the group is a member of the up-role. The Research on the arbac97 management model is still in progress. The formalization of capabilities-assignment and group-assignment has been basically completed, and the research results on the up-role concept have not yet been formally formulated. [2] drbacdrbac is a distributed RBAC model in a dynamic Association environment. Unlike the previous Trust Management and RBAC methods, drbac supports three features: 1. third-party assignment: if an entity is authorized to assign an assignment, it can be assigned a role other than its namespace. 2. Numeric attribute: Adjust the access permission by assigning a mechanism to process role-related values. 3. Assignment monitoring: Use the pub/sub structure to continuously monitor the established trust relationship to track the canceled assignment status. Drbac is caused by resource access control in an alliance environment. The "Alliance Environment" can be a joint goal of several military countries, or a partnership of several commercial companies. The Alliance Environment defines that multiple organizations or entities do not have a common trusted authorization center. In this case, while protecting their respective resources, the entity must collaborate to share the part of the protected resources necessary for the Alliance. The growth of network services on the Internet has made such a common demand. Drbac combines the advantages of RBAC and the trust management system. It is a flexible, decentralized, and scalable system. Drbac indicates that the role is defined in the trust domain of an entity and can be transferred to other roles in different trust Domains Based on the controlled behavior of the role. Drbac uses PKI to identify all entities related to trust-sensitive operations and confirm the assignment of certificates. The ing from the role to the authorized namespace avoids the need to confirm the root cause of the additional policy. 4. Edit the license Configuration

License configuration instructions

The elements of Role-Based Access Control include users, roles, permissions, and other basic definitions. In RBAC, a user is the subject that can independently access data in the computer system or other resources represented by data. A role is a work or position in an organization or task. It represents a right, qualification, and responsibility. A permission is an operation that allows one or more objects to be executed. A user can have multiple roles authorized. A role can be composed of multiple users. Each role can have multiple licenses, and each license can be authorized to multiple roles. Each operation can be applied to multiple objects (controlled objects), and each object can also accept multiple operations. The User table (users) includes the user ID, user name, and user logon password. A user table is a set of individual users in the system. It dynamically changes with the addition and deletion of users. The role table (roles) includes the role ID, role name, role base, and role available identity. A role table is a set of system roles defined by the system administrator. The object table (objects) includes the Object ID and Object Name. An object table is a collection of all controlled objects in the system. The Operations table includes the operation identifier and Operator name. The operator operators of all controlled objects in the system constitute the Operator table. Permissions includes the license id, license name, controlled object, and Operation ID. The license table shows the correspondence between controlled objects and operators. The role/license authorization table includes the role ID and license id. The system administrator assigns a role or cancels the permission to manage the role/license authorization table. The basic idea of RBAC is that the access permissions granted to users are usually determined by the roles of users in an organization. In RBAC, the role is authorized to the user, and the user is not directly associated with the permission. RBAC grants access permissions centrally managed by administrators. RBAC grants access authorization and control based on the roles of users in an organization. Authorization rules are imposed on users, users cannot pass access permissions to others independently. This is an autonomous centralized access control method. For example, a doctor in a hospital can prescribe a prescription, but he does not have the right to pass the prescription to a nurse. In RBAC, user identity is very useful for identity authentication and audit records. However, what determines the access permission is the role identity of the user. When a user can perform access operations on an object, the user is granted a certain role, one of which is active at the current time, in addition, this role has access permissions to the object. That is to say, RBAC uses roles as the subject of access control. What roles a user uses to access resources determines what operations the user can perform. ACL directly links the subject with the controlled object, while RBAC adds a role in the middle to communicate the subject with the object through the role. The advantage of layering is that when the subject changes, you only need to modify the association between the subject and the role, instead of modifying the association between the role and the object. The editing of the 5rbac model meets the security management requirements of various organizations. RBAC models support the principle of least privilege and separation of responsibilities. These principles are required by any organization's management work. This gives RBAC models a wide range of application prospects. RBAC model supports data abstraction principles and inheritance concepts. Because mainstream programming languages currently support object-oriented technology, RBAC is easy to implement in actual systems. The concepts in the model are closely related to the actual system. The role, user, and permission concepts in the RBAC model are the actual entities of the actual system, so that the designer can establish the existing or the RBAC model of the system to be created. The RBAC model still has an access control model. In essence, it is an extension of the Access Matrix Model, which can effectively solve the problem of politely controlling the distribution and control of access permissions in the system, however, the model does not provide information flow control mechanisms and cannot fully meet all the security requirements of the information system. Although some people think that RBAC can be used to simulate a lattice-Based Access Control System (lbac), RBAC is not intuitive in controlling internal information flows of the system and requires support from functions outside the model. The Scope Principle of information flow control is introduced in chapter 4. Readers can further understand this defect of RBAC model. The RBAC model does not provide an operation sequence control mechanism. This defect makes it difficult for RBAC models to apply entity systems that require strict operation orders. For example, in a shopping control system, the system must control the purchase steps, the customer should not take the goods away before the payment is made. The RBAC model requires that this control mechanism be put out of the model for implementation. Both the RBAC96 model and the rbac97uanli model deliberately avoided some problems, such as whether to allow a user in the session to create another session, the management model does not support the addition and deletion of users and permissions. It is a problem that needs to be solved but not supported. These problems are still being studied, however, without the support of these capabilities, the application of the model will also be affected. On the contrary, the Access Matrix Model provides the user and permission modification functions. Therefore, it cannot be said that the RBAC model can completely replace the Access Matrix Model.

RBAC (Role-Based Access Control)