A Cross-Tenant RBAC Model for Collaborative Cloud Services

: Tenants in the cloud computing environment share various services, including storage, network, computing, and applications. For better use of services in the cloud computing environment, tenants collaborate in tasks, resulting in challenges to the traditional access control. This study proposes a cross-tenant role-based access control (CT-RBAC) model for collaborative cloud services. This model covers the CT-RBAC0, CT-RBAC1, CT-RBAC2, and CT-RBAC3 models. The model not only extends the RBAC model in the multi-tenant cloud computing mode but also includes four types of authorization modes among tenants. Consequently, the role inheritance constraint is increased, and fine-grained authorization access among trusted tenants is realized.

organizations and utilize independent management authorization platforms. Therefore, these methods cannot adequately adapt to the characteristics of cloud computing. Current Infrastructure as a Service (IaaS) cloud platforms have their own authorization system, containing different access control policies and models. Clients with accounts in multiple cloud providers struggle to manage their rules in order to provide a homogeneous access control experience to users. Sette et al. [Sette, Chadwick and Ferraz (2017)] proposes a solution: an Authorization Policy Federation (APF) of heterogeneous cloud accounts. To realize collaboration among different tenants, Tang et al. [Tang (2013)] proposed the administration of a multi-tenant approval system (MTAS) in combination with the RBAC model. Trust conditions were added to the AMTAS model, which performs formal analysis of trust among different tenants, based on MTAS. Later, the MT-RBAC model was proposed based on AMTAS [Tang, Sandhu and Li (2015)]. This model extends the traditional RBAC model, increases two built-in components (issuer and tenant), and realizes collaboration of different tenants by setting up the trust relationship among different tenants. The MT-RBAC model integrates three different tenant trust models, namely, MT-RBAC0, MT-RBAC1, and MT-RBAC2. MT-RBAC0 is the basic model and requires all trustors to gather all roles and expose corresponding authorization to the trustee. To restrict unnecessary authorization information of trustors, the MT-RBAC1 model divides the role set into two subsets, in which the public role is exposed to all trustees. The MT-RBAC2 model provides more detailed constraints and offers different role authorization sets according to the trust level of trustees. Based on the MT-RBAC, a cross-tenant RBAC (CT-RBAC) model is proposed in this study. Based on the extensively used RBAC96 [Sandhu (1997)] (RBAC0, RBAC1, RBAC2, and RBAC3), the proposed CT-RBAC model is used to design the CT-RBAC0, CT-RBAC1, CT-RBAC2, and CT-RBAC3 models. Compared with the MT-RBAC model, the CT-RBAC model not only considers different types of authorization modes among different tenants, the exposure of users and role information in authorization, and management of role inheritance but also extends the RBAC model in the multi-tenant cloud computing mode.

Equations and mathematical expressions
The CT-RBAC model covers the unilateral trust relationships among different types of tenants. Trustors and trustees can set up flexible trust relationships according to practical demands. Definition 1: T refers to the set of all tenants, and the trust relationship of all tenants is a multiple-to-multiple relationship. For ∀t i, tj∈T, ti is the trustor, and tj is the trustee, which is denoted as ti◃ tj. If ti and tj represent the same tenant, then ti ≡ tj.
The ∀ti, tj, tk∈T, and TT relationship includes the following properties: (1) Self-inspective: ti◃ ti (2) Inverse transmission: ti◃ tj∧ti◃ tk ⇏ ti◃ tk (3) Antisymmetry: ti◃ tj∧tj◃ ti⇏ ti≡tj Property 1 reflects that one tenant always trusts himself/herself, and intra-tenant access is uninfluenced by the trust relationship. Property 2 demonstrates that the trust relationship between any two tenants causes no influence on the trust relationships of another two tenants with other tenants. Property 3 reveals that one trust relationship is one-way and independent, and the mutual trust between two tenants cannot prove that the two tenants are the same tenant. Four types of trust relationships that can realize cross-tenant access are introduced [8] , namely, Type-α, Type-β, Type-γ, and Type-δ. The trust relationship of tenants involves four key problems. (1) Who is responsible for managing the trust relationship? (2) Who is responsible for authorization behavior? (3) Who provides resources? (4) Who is the authorization object? Considering ∀ti, tj∈T, ti◃ tj, in all four types, trustor ti is held responsible for the maintenance of trust relationship. Tab. 1 shows the differences among the four types of trust relationships.

CT-RBAC model
To realize the fine-grained cross-tenant RBAC model for collaborative cloud services, the structure of the CT-RBAC model is designed first. Subsequently, the formal definition of the CT-RBAC model is provided, and model operations are defined. Finally, the model constraints are discussed.

CT-RBAC structure
As shown in Fig. 1, the CT-RBAC model comprises five parts, namely, tenants (T), users (U), roles (R), permissions (P), and sessions (S). Compared with the traditional RBAC model, the CT-RBAC model includes an additional tenant module and a built-in tenant attribute in U, R, and P for constructing one-to-multiple role ownership (RO) relations between roles and tenants, one-to-multiple user ownership (UO) relations between users and tenants, and one-to-multiple permission ownership (PO) relations between permissions and tenants. In other words, users, roles, and permissions all belong to one tenant in the CT-RBAC model. In the cloud computing environment, the CSP uses tenant as a logic unit to provide user storage, computing, network, and application services. T can be either an organization or a working unit. For instance, a tenant in the IaaS CSP offers 100 GB of memory space, and he/she can distribute the right to use memory space to internal users according to his/her needs. In the present study, the tenant set is denoted as T. Users (U): User is a subject with access to resources in one tenant independently. A user might be a person, a machine, or a system. Users belong to one tenant, and one tenant can include multiple users. Here, the user set is denoted as U, and the relationship between users and tenants can be expressed by @. For example, user uj in tenant ti can be expressed as ti@uj. Roles (R): One role is the object in a tenant that can implement a specific work or responsibility. R represents qualification, rights, and responsibility. R belongs to any tenant, and one tenant can cover multiple roles. The role set is denoted by R, and the relationship between roles and tenants is expressed by #. For example, role rj in tenant ti is expressed as ti#ri. Permissions (P): Permission refers to the access permission of one or multiple objects in one tenant to access in a specific mode. Permission is related with implementation details, such as reading and writing of a document in the system. Permission belongs to one tenant, and one tenant can cover multiple permissions. Here, a permission set is denoted by P, and the relationship between permissions and tenants is expressed by %. For example, permission pj in tenant ti can be expressed as ti%pj.
Sessions (S): Session is a temporary activity established by one user. A session is constructed when one user activates the subset of all roles. Each session is connected with single users, and each user can be related with one or multiple sessions. Sessions about the activated roles of users in the cross-tenant cloud computing environment may be included in more than one tenant. The trust relationship among tenants must be set up to realize their colorations. The CR-RBAC model introduces a trust relationship based on roles. Fig. 2 shows the trust relationships among tenants.

Definition of models
The CT-RBAC model covers four models, namely, the CT-RBAC0, CT-RBAC1, CT-RBAC2, and CT-RBAC3 models. These four models extend the RBAC0, RBAC1, RBAC2, and RBAC3 models, which are family members of the RBAC96 model. The formal definition of the CT-RBAC0 model is introduced as follows. Definition 2. The CT-RBAC0 model contains the following components: T, U, R, P, S, and TT are finite sets of tenants, users, roles, permissions, sessions, and trust relationship of tenants, respectively.  UO⊆U×T represents the mapping of relationship between each user and the tenant (multiple-to-one relationship) and is also recorded as "@". Accordingly, userOwner(u:U)→T is a function that maps the relationship between one user and the corresponding tenant. Here, userOwner(u) = t only when (u,t)∈UO.  RO⊆R×T reflects the mapping of relationship between each role and the tenant (multiple-to-one relationship); it is denoted as "#". Accordingly, roleOwner(r:R) →T is a function that maps the relationship between one role and the corresponding tenant. In the present study, roleOwner(r) = t only when (r,t)∈RO.
 PO⊆P×T implies the mapping of relationship between one permission and the tenant (multiple-to-one relationship), and it is also denoted as "%". Accordingly, permOwner(p:P)→T is a function that maps the relationship between one permission and the corresponding tenant. permOwner(p) = t only when (p,t)∈PO.  PA⊆P×R is the multi-to-multi relationship between one permission and one role. It shows the permissions to assign roles. (p,r) ∈ UA only when permOwner(p) ∈ canUse(r).
 user(s:S)→U maps a function between each session and one user who is in the stated period of the session.
 roles(s:S)→2 R is the role set in the life span of each session. roles(s) ⊆{r ∈ roles|(user(s,r) ∈UA∧userOwner(user(s))∈canUse(r)}. The CT-RBAC0 model is the core model of CT-RBAC, and it allows setting up different types of trust relationships (Type-α, Type-β, Type-γ, and Type-δ) among different tenants. In authorization, the trust relationship is managed by trustors. The authorization party can assign roles to users according to different types of trust relationships, but he/she is forbidden to assign roles for CTs.
Type-α: ti must set up a trust relationship between two tenants when ∀ti, tj∈T, and ti◃ tj to realize CT access. tj sets the PU between two tenants, ti sets the PR between two tenants, and ti accomplishes the authorization process.
Type-β: ti must set up a trust relationship between two tenants when ∀ti, tj∈T, and ti◃ tj to realize CT access. ti sets the PU between two tenants, tj sets the PR between two tenants, and tj accomplishes the authorization process.
Type-γ: ti must set up a trust relationship between two tenants when ∀ti, tj∈T, and ti◃ tj to realize CT access. tj sets the PU between two tenants, ti sets the PR between two tenants, and tj accomplishes the authorization process.
Type-δ: ti must set up a trust relationship between two tenants when ∀ti, tj∈T, and ti◃ tj to realize CT access. ti sets PU and the PU between two tenants, whereas tj accomplishes the authorization process. According to the analysis of the authorization of four types of trust relationships, the CT-RBAC0 model can avoid leakage of user information and role information, thereby increasing system security. Tenants can manage the PU and PR after setting up the trust relationship. PU and PR are deleted automatically after the removal of trust relationship. Among the RBAC96 models, RBAC1 involves a role inheritance compared with the core model. Similarly, the CT-RBAC1 model adds role inheritance relative to the CT-RBAC0 model. The inheritance of the CT-RBAC1 model covers the role inheritance in one tenant and that among different tenants. The role inheritance in one tenant in the CT-RBAC1 model follows the inheritance method of the RBAC1 model. However, the role inheritance among different tenants mainly features the following problems. (1) Who is responsible for setting up the roles? (2) Who provides the inheriting role? (3) Who offers the inherited role? (4) Who is responsible for managing role inheritance? To prevent exposure of role information, all roles in CT-RBAC1 are accomplished in the same tenant rather than among different tenants. Among the four types of trust relationships, the CT-RBAC1 model realizes CT role inheritance according to the following three rules. Rule 1: Resource supplier (role) offers the inherited role. Rule 2: The user who provides the access resources offers the inheriting role. Rule 3: The authorization person is responsible for role inheritance management. Tab. 2 presents the inheritance modes among tenants in the four types of trust relationships given ∀ti, tj∈T, and ti◃ tj. To prevent exposure of information on the inheriting role and inherited role, the set of inheriting roles and set of inherited roles that must be respectively exposed shall be established in a different tenant. The set of inherited role overlaps with the PR. Definition 3. CT-RBAC1 inherits all components of CT-RBAC0 and meets the following conditions:  PRH (ti,tj:T)→2 R is the function of the role set in tenant ti that can be inherited by the roles in tenant tj.  RH⊆R×R is the partial ordering relations on a role set and is also called role inheritance and recorded as "≥"r. ri≥rj only when roleOwner(ri) ≡roleOwner(rj)∨ (rj∈PR∧ri∈PRH). If one role can inherit another role, then this role and the inherited role are either in the same tenant, or the role is in the inheritable CT role set. Meanwhile, the inherited role must be in the set of tenants that can authorize the inherited role.


Restricted inheritance: ∀r,r1,r2∈R; r≥r1 r≥r2⇒r1=r2. The CT-RBAC1 model allows tenants to realize role inheritance under four types of trust relationships. The setting of roles at CT inheritance must be achieved by tenant managers. The inheritance modes of the four types of trust relationships are introduced as follows: Type-α: ti must set the PR between two tenants, whereas tj sets the PRH between two tenants, and ti inherits roles when ∀ti, tj∈T and ti◃ tj to realize CT access.
Type-β: tj must set the PR between two tenants, whereas ti sets the PRH between two tenants, and tj inherits roles when ∀ti, tj∈T and ti◃ tj to realize CT access.
Type-γ: ti must set the PR between two tenants, whereas tj sets the PRH between two tenants and inherits roles when ∀ti, tj∈T and ti◃ tj to realize CT access.
Type-δ: ti must set the PR and PRH between two tenants, whereas tj inherits roles when ∀ti, tj∈T, and ti◃ tj to realize CT access.
The RBAC2 model involves additional constraints, including static responsibility separation and dynamic responsibility separation, based on the RBAC0 model. Unlike the RBAC2 model, the constraint of the CT-RBAC2 model exists not only in the same tenant but also between tenants. Definition 4. Static responsibility separation. SSD 2 R ×N. This relationship satisfies the following: ∀(rs,n)∈SSD, and ∀t rs:|t|≥n⇒ = , where rs is a set of roles, t is a subset of rs, and n is a natural number higher than 2. The role set where rs lies not only covers roles in the same tenant but also roles that trust tenants can use. Definition 5. Dynamic responsibility separation. DSD 2 R ×N. This relationship satisfies the following: ∀rs∈2 R , n∈N, and (rs,n)∈D ⇒n≥2 |rs|≥n. Moreover, ∀s ∈ S, ∀rs ∈ 2 R , ∀role_set ∈ 2 R , n ∈ N, (rs,n) ∈ D, role_set rs, and role_set session_roles(s) ⇒|role_set|<n. Definition 6: CT-RBAC2 inherits all components of CT-RBAC0 and satisfies the following conditions:  It conforms to the static responsibility separation.  It conforms to the dynamic responsibility separation. Definition 7: Inheritance ring. Among mutually trusted tenants, the role inheritance among new tenants forms a ring-shaped inheritance structure, which is called the inheritance ring.

Operations of the CT-RBAC model
The operations of the CT-RBAC model mainly include the functions used by the manager of the cloud platform, the management function used by tenant managers, and the functions used by CT managers. The functions used by CT management determine who uses the functions according to the type of trust relationships among different tenants. Tab. 3 lists the major operation functions of the models. In cross-tenant access functions, the system can remove all access relations among tenants automatically when the tenant trust is revoked, including accessible users, accessible roles and authorization relationships of users. Similarly, the system removes authorization and inheritance of an accessible role automatically when this role is revoked from users. The rest cross-tenant access functions can be done in the same way.

Conclusions
Security is one of the core problems in cloud computing. In the present study, a CT-RBAC model is proposed to solve authorization problems caused by the collaboration of tenants in the cloud computing environment. At the same time, the structure, formalized definition, and operations of the model are interpreted. The proposed model possesses the characteristic of inheriting the minimum privilege principles and responsibility separation rules of the RBAC model. The model also realizes the fine-grained CT RBAC model for collaborative cloud services by the exposure of user and role information within the authorization and role inheritance constraint.