# Role-Based Access Control Model for Inter-System Cross-Domain in Multi-Domain Environment
## 2 Related Work  
[PERSON] et al. introduced the concepts of role hierarchy, constraint, etc., extended RBAC into four forms and collectively called it the RBAC96 model [13]; most of the later RBAC improvement schemes depended on the RBAC96 model. Later, [PERSON] et al. proposed the ARBAC97 model [14], which divides the roles into mutually exclusive regular roles and administrative roles granted to the security administrators in the system; ARBAC97 standardizes and defines the operations of administrative roles to regular roles within the system. [PERSON] et al. proposed a standard for RBAC [15], which defines some components of RBAC and their semantics, and regulates the operation and management of RBAC; The standard plays a normative role for subsequent RBAC research work. However, when solving inter-system cross-domain access control problems, if these traditional RBAC models are used, it can lead to a situation of role explosion [16], resulting in many redundant roles with similar permissions and easy confusion. There have been many studies on improving the RBAC model to solve the shortcomings of the traditional RBAC model. [PERSON] et al. proposed a dynamic access control model AW-TRBAC [17], which assigns tasks according to users' roles, and access permissions are only available when tasks are executed in the workflow. The dynamic nature of the model alleviates the role explosion problem, but the security administrator does not define the management scope in the model and cannot resolve the inter-domain management conflict. In references [18; 19; 20], the concept of multi-dimensional roles is proposed to isolate tenants. Among them, reference [20] uses 4D-Role with user categories, and user categories include tenant users and platform users, making cloud platform management independent of tenant management. Strictly isolating users among different tenants is beneficial to privacy protection, but it is not conducive to information sharing among tenants. [PERSON] et al. proposed a distributed role-based access control (dRBC) [21]. In dRBC, each entity uses its own name as the namespace of its publishing role, and the entity can delegate the role assignment rights to other entities, which in turn reduces role naming conflicts and permission sharing. However, these assignment rights can be passed so continually that it cannot control its indirect delegation. [PERSON] et al. [22] proposed a multi-tenant RBAC model for collaborative cloud services. The issuer of the truster establishes a trust relation with the trustee, and the users in the trustee can authorize the roles in the trustee to complete multi-tenant data sharing and isolation. The issuer needs to rely on each trustee to establish public role sets, and the truster cannot control the trustee's user authorization. [PERSON] et al. [23] used the role-to-role (RTR) mapping rules to map a role in the organization with other organizational roles through the proposed role mapping algorithm, so that users can share other organizational resources. References [24; 25; 26], respectively, use inter-domain role mapping (IDRM) and role cross-domain inheritance to solve the problem of cross-domain sharing. References [23; 24; 25; 26] have the same defects as in reference [22]. The truster domain cannot control how the trustee domain administrator authorizes roles to users, and the grain is coarse. [PERSON] et al. proposed an RBAC architecture for multi-domain cloud environment [27]. Service providers and the domain administrators are, respectively, responsible for access control and access control policy management. There is a certain isolation between the service provider and the domain, but the service provider is allowed to modify the domain policies. Following that modification, the domain administrator needs to review and redefine the policy, which increases the management burden of the domain administrator.