# A 4D-Role Based Access Control Model for Multitenancy Cloud Platform

Authors: Jiangfeng Li; Zhenyu Liao; Chenxi Zhang; Yang Shi
Journal: Mathematical Problems in Engineering
 (2016)

---

## Abstract

Since more and more applications and services have been transferred from servers in the B/S architecture to cloud, user access control has become a significant part in a multitenancy cloud platform. Role based access control model makes users participate in an enterprise system as particular identities. However, in a multitenancy cloud environment, it has a high probability that the information of tenants has been leaked by using existing role based access control (RBAC) model. Moreover, management problems may emerge in the multitenancy platform with the increment of the number of tenants. In this paper, a novel concept of 4D-role is presented. With a detailed definition on the concept of 4D-role, a 4D-role based multitenancy model is proposed for running various applications and services in the multitenancy cloud platform. A theoretical analysis indicates that the model has the characters of tenant isolation, role hierarchy, and administration independence. The three characters are also verified by experimental evaluation. Moreover, the evaluation results indicate that the model has a good performance in using cloud resources when large-scale users are operating in the cloud platform simultaneously.


---

## Body

## 1. Introduction

With the rapid development in computer technology, more and more applications and services have been transferred from servers in the B/S architecture to cloud platforms. In the last decade, cloud computing has attracted plenty of enterprises by its powerful processing capabilities, large storage, and low cost. As cloud computing gains popularity, it is a necessity that cloud-service providers must consider several issues when they offer services to customers, such as the safety of customer privacy, and the shifting of the original authorization. Multitenancy is a key technology for nearly every cloud computing platform, and the main purpose of it is to separate user data and ensure that users are not influenced by each other [1]. The technology makes a cloud provider able to rent its services to multiple tenants simultaneously. However, how the tenants in a multitenancy environment can access resources safely is a significant problem that needs to be solved. Moreover, it is quite necessary to find solutions that make the cloud provider manage different tenants efficiently.Role based access control (RBAC) model has been widely applied to authorize certain users to access certain data or resources within complex systems [2–6]. In the role based access control model [7–10], role is a collection of access rights or permission. It is a concept of one-dimensional space. Role is also considered as a binary vector of authority and scope in [11], which is a concept of two-dimensional space. Moreover, considering that users participate in an enterprise system as a particular identity, it results in that roles of different users have different authorities, and each authority is valid in a relevant scope during its permission time. So, a three-dimensional role based user management model is proposed [12]. The three-dimensional role is defined as a vector composed of authority, scope, and permission time. Figure 1 gives a sketch of multidimensional roles in the existing access control models.Figure 1
A sketch of multidimensional roles in access control models.
(a)
One-dimensional role
(b)
Two-dimensional role
(c)
Three-dimensional roleAlthough the existing RBAC model has considered three dimensions, it still has a high probability of information leakage in the multitenancy environment. Since RBAC based systems administer user authorization using a centralized control mechanism [13–15], there may be various RBAC strategies serving in the multitenancy environment. This often results in information leakage. On the other hand, management problems may emerge in the multitenancy cloud platform employing the existing RBAC model. In the multitenancy environment, RBAC authorizing mechanisms established by different enterprise managers are applied to a distribution environment [16], which also causes management problems.In order to solve the problems above, it is necessary for the multitenancy cloud platform to have characters of tenant isolation, role hierarchy, and administration independence. The character of tenant isolation, which is the isolation for the operational fields of tenants, prevents a customer’s data from being violated by other tenants. Role hierarchy means that roles of tenant users and administrator users construct hierarchical structures. It makes the multitenant cloud provider manage tenants who establish role authorizing mechanism efficiently. Administration independence ensures the cloud administration independent of any tenancy application. It not only prevents tenant information from being leaked by cloud provider, but also brings benefits for solving management problems in multitenancy cloud platform.In this paper, we focus on designing an authorization mechanism in multitenancy environment, in order to protect cloud tenant’s privacy and improve the efficiency of the cloud management. The contributions of the paper include the following: (1) a novel concept of 4D-role is proposed; (2) a 4D-role based multitenancy model is constructed in Section2; (3) three characters of the model, tenant isolation, role hierarchy, and administration independence, are analyzed theoretically by proving in mathematical approaches in Section 3; (4) Experimental evaluation was performed in Section 4 to verify the model.


## 2.
4D-Role Based Multitenancy Model

In the multitenancy environment in cloud platforms, a user’s role is not invariable. It varies dynamically in terms of the changing of enterprise activities. So, the system should grant multiple roles dynamically with the development of enterprise. In our definition, role is a combination of permission, scope, valid time, and user category, which is composed of a four-dimensional space. In this section, we introduce the 4D-role and the 4D-role based multitenancy model.


### 2.1. Basic Concepts

Definition 1 (basic permission).
Basic permission is an access operation that a system owns, which is an atomic operation and cannot be divided any more. LetB
=
b
1
,
b
2
,
b
3
,
…
,
b
n
b be the set of all basic permissions, where b
i is the ith basic permission.Definition 2 (permission).
Permission is a union of finite basic permissions. A permission that containsm
(
m
≤
n
b
) basic permissions is formulated as p
=
⋃
i
=
1
m
b
i
(
b
i
∈
B
). Let P
=
p
1
,
p
2
,
p
3
,
…
,
p
n
p be the set of all permissions, where p
i is the ith permission.
The basic permission and the permission give the operation types that are using the cloud platform.Definition 3 (scope).
Scope is an operation place where the permitted operation is valid in a cloud platform. The scope is related to a permitted operation. LetS
=
s
1
,
s
2
,
s
3
,
…
,
s
n
s be the set of all scopes, where s
i is the ith scope.
The scope specifies the area where an operation is valid in the cloud platform.Definition 4 (valid time).
Valid time is the period of time when a permitted operation is allowed to be operated in a cloud platform. A valid timet
=
[
t
begin
,
t
end
] is a closed interval from a starting time t
begin to an ending time t
end. Let T
=
t
1
,
t
2
,
t
3
,
…
,
t
n
t be the set of all valid time, where t
i is the ith valid time.
The valid time points out a period of time when an account is allowed to operate in a cloud platform. Time is increasing without a bound. However, an account in the cloud platform may have an expiration date or time. For instance, accounts of an enterprise that rents cloud resources for one year expire after one year. In another case, the valid time of a staff’s account ends at the day he leaves the enterprise.Definition 5 (user category).
User category is a class that a user belongs to in cloud platforms. LetC
=
c
1
,
c
2
,
c
3
,
…
,
c
n
c be the set of all categories, where c
i is the ith category.The user category makes sure to which type a user account belongs.There are various users in the cloud platform. Such users can be divided into some categories according to the user type. For example, users may be put into categories of normal user, senior user, and administrator user.


### 2.2.
4D-Role and 4D-Role Based User Group

#### 2.2.1.
4D-Role

In a multitenancy cloud platform, users are divided into two categories. One is the category of tenant user. The tenant users, such as enterprise staffs, are those users who rent the cloud resources and use the cloud platform. The other is the category of platform user. The platform users operate and manage the cloud platform. Such works include assigning new resources to tenant users and managing the accounts of tenant users. So, according to Definition5 in Section 2.1, there are two user categories in our cloud platform. The set of user category is C
=
c
1
,
c
2, and c
1
=
tenant and c
2 = platform.Definition 6 (role, tenant role, and platform role).
(1) Role is a set of finite tuples formed asp
,
s
,
t
,
c. A role is represented as r
=
p
,
s
,
t
,
c, where p
∈
P
,
s
∈
S
,
t
∈
T
,
c
∈
C. Let R
=
r
1
,
r
2
,
r
3
,
…
,
r
n
r be the set of all roles, where r
i is the ith role.
(2) Letr
=
p
,
s
,
t
,
c be a role:
(a)
The roler is a tenant role, if and only if c
=
tenant.
(b)
The roler is a Platform Role, if and only if c
=
platform.From Definition 6, we can find that the role is a four-dimensional concept. A role has permissions in relevant scopes during the period of valid time. One kind of permission comprises a few basic permissions. Also, there are two types of role, tenant role and platform role.


#### 2.2.2.
4D-Role Based User Group

A multitenancy cloud platform is a user operation oriented platform. There are a large number of users in a practical cloud platform, which makes user management complicated. In order to make things simpler, we could consider a group of users who have the same permissions, scopes, valid time, and user category.Definition 7 (user group, tenant user group, and platform user group).
(1) User group, which is composed of finite roles, is a set of unions of finite roles. A user group that includesk
(
m
≤
n
r
) roles is formulated as g
=
⋃
i
=
1
k
r
i
(
r
i
∈
R
). Let G
=
g
1
,
g
2
,
g
3
,
…
,
g
n
g be the set of all user groups, where g
i is the ith user group.
(2) Letg
=
⋃
i
=
1
k
r
i
(
r
i
∈
R
) be a user group.
(a)
The user groupg is a tenant user group, if and only if every r
i is a tenant role.
(b)
The user groupg is a platform user group, if and only if every r
i is a platform role.Definition 8 (tenant).
A tenant is a set of tenant user groups which are in the same enterprise. A tenant has the following properties:(1)
LetG
A be a tenant whose user groups are in the enterprise A:(1)
∀
g
m
a
=
⋃
m
i
p
k
m
i
a
,
s
n
m
i
a
,
t
l
m
i
a
,
c
h
m
i
a
∣
p
k
m
i
a
∈
P
,
s
n
m
i
a
∈
S
,
t
l
m
i
a
∈
T
,
c
h
m
i
a
=
Tenant
∈
G
A
.
(a)
The union of all permissions inG
A is P
A
=
⋃
m
⋃
m
i
p
k
m
i
a
=
⋃
j
b
j
(
a
)
⊆
B, where b
j
(
a
) is the jth basic permission in the set of all basic permissions in Tenant G
A.
(b)
The union of all scopes inG
A is S
A
=
⋃
m
⋃
m
i
s
n
m
i
a
⊆
S.
(2)
LetG
A and G
B be two tenants whose user groups are in enterprises A and B, respectively:(2)
∀
g
m
a
=
⋃
m
i
p
k
m
i
a
,
s
n
m
i
a
,
t
l
m
i
a
,
c
h
m
i
a
∣
p
k
m
i
a
∈
P
,
s
n
m
i
a
∈
S
,
t
l
m
i
a
∈
T
,
c
h
m
i
a
=
Tenant
∈
G
A
,
∀
g
m
′
b
=
⋃
m
i
′
p
k
m
i
′
b
,
s
n
m
i
′
b
,
t
l
m
i
′
b
,
c
h
m
i
′
b
∣
p
k
m
i
′
b
∈
P
,
s
n
m
i
′
b
∈
S
,
t
l
m
i
′
b
∈
T
,
c
h
m
i
′
b
=
Tenant
∈
G
B
.
G
A
=
G
B, if and only if(3)
⋃
m
⋃
m
i
p
k
m
i
a
=
⋃
m
′
⋃
m
i
′
p
k
m
i
′
b
,
⋃
m
⋃
m
i
s
n
m
i
a
=
⋃
m
′
⋃
m
i
′
s
n
m
i
′
b
,
⋃
m
⋃
m
i
t
l
m
i
a
=
⋃
m
′
⋃
m
i
′
t
l
m
i
′
b
.
(3)
LetG
1
,
G
2
…
,
G
w be w tenants in the cloud platform. Each S
i
(
1
≤
i
≤
w
) is the union of all scopes in G
i. S is the universal set of scopes in the cloud platform. The set W
=
{
S
1
,
S
2
,
…
,
S
w
,
S
-
⋃
i
=
1
w
S
i
} is a partition to S.From the definitions above, we know that the union of all permissions in a tenant has boundary. It is the same as the union of all basic permissions in the tenant. The scope in a tenant also has boundary. A partition of scopes in the cloud platform is defined to ensure that user groups in each tenant have isolated environment in operating in the cloud platform.In addition, we can find the relations among user group, role, permission, and basic permission. A user group is a set of roles, and a tenant is made up of several user groups which are in the same enterprise. As a role consists of permission, scope, valid time, and user category, in the 4D-role based multitenancy model, permissions are assigned to a user group through 4D-role. Basic permissions are able to be assigned to a user group according to the mapping from permission to basic permission. Figure2 shows the relation among user group, role, permission, and basic permission.Figure 2
Relations among user group, role, permission, and basic permission.


### 2.3. User in the 4D-Role Based Multitenancy (4D-RBMT) Model

#### 2.3.1.
4D-Role Based User

Definition 9 (user, tenant user, and platform user).
(1) User is a member of user group. A user belongs to one of user groups. LetG be the set of all user groups and let u
i
,
j be a user. ∀
g
∈
G, if u
i
,
j
∈
g
i, then u
i
,
j is called the jth user of g
i.
(2)u
i
,
j is a tenant user, if and only if g
i is a tenant user group.
(3)u
i
,
j is a platform user, if and only if g
i is a platform user group.
LetU be the set of all users: (4)
U
=
u
1
,
u
2
,
u
3
,
…
,
u
n
,where U is the number of elements in set U and u
i is the ith user.Theorem 10.
User is a union of finite roles.Proof.
LetU be the set of all users and let G be the set of all user groups.
∀
u
∈
U, ∃
g
i
∈
G, such that
u
∈
g
i.
Note that(5)
g
i
=
⋃
j
r
j
∣
r
j
∈
R
,
1
≤
j
≤
R
.Therefore (6)
u
=
⋃
j
0
r
j
0
,where r
j
0
∈
R, 1
≤
j
0
≤
R.


#### 2.3.2. Hierarchy of 4D-Role Based Users

There are six types of users in a multitenancy cloud platform. Such users belong to two kinds of users: platform user and tenant user.(1) Platform user is described as follows.(
a) General Admin. It is the super administrator in the model. New applications and user categories in the cloud platform are set by the General Admin.(
b) Developer. It sets the basic permissions in the multitenancy cloud platform. There are two kinds of basic permissions in the platform. One is the kind of basic permission that is used to run programs for managing the multitenancy cloud platform. The other is the kind of basic permission that is used to run programs for managing applications in the cloud platform. The account of a developer is approved by the General Admin.(
c) Platform Senior Admin. It is responsible for configuring the permission, scope, valid time, role, and user group in the cloud platform. The highest level account, in the hierarchy of the Platform Senior Admin, is approved by a Developer. Also, a Platform Senior Admin is able to add accounts of lower level Platform Senior Admin.(
d) Platform Admin. It is the ordinary administrator to manage the cloud platform. The account of a Platform Admin is approved by a Platform Senior Admin.(2) Tenant user is described as follows.(
a) Application Administrator. It is responsible for configuring the permission, scope, valid time, role, and user group in the application system. An Application Administrator is able to add accounts of lower level Application Administrators. The highest level account, in the hierarchy of Application Administrator, is approved by a Developer.(
b) Application User. It is the terminal user to use an application.The six types of users above are divided into four levels, according to their duties in the cloud platform. General Admin is in level 1. Developer belongs to level 2. Level 3 contains Platform Senior Admin and Application Administrator. Level 4 includes Platform Admin and Application User. Figure3 shows the user hierarchy in the 4D-RBMT model.Figure 3
User hierarchy in the 4D-RBMT model.


## 2.1. Basic Concepts

Definition 1 (basic permission).
Basic permission is an access operation that a system owns, which is an atomic operation and cannot be divided any more. LetB
=
b
1
,
b
2
,
b
3
,
…
,
b
n
b be the set of all basic permissions, where b
i is the ith basic permission.Definition 2 (permission).
Permission is a union of finite basic permissions. A permission that containsm
(
m
≤
n
b
) basic permissions is formulated as p
=
⋃
i
=
1
m
b
i
(
b
i
∈
B
). Let P
=
p
1
,
p
2
,
p
3
,
…
,
p
n
p be the set of all permissions, where p
i is the ith permission.
The basic permission and the permission give the operation types that are using the cloud platform.Definition 3 (scope).
Scope is an operation place where the permitted operation is valid in a cloud platform. The scope is related to a permitted operation. LetS
=
s
1
,
s
2
,
s
3
,
…
,
s
n
s be the set of all scopes, where s
i is the ith scope.
The scope specifies the area where an operation is valid in the cloud platform.Definition 4 (valid time).
Valid time is the period of time when a permitted operation is allowed to be operated in a cloud platform. A valid timet
=
[
t
begin
,
t
end
] is a closed interval from a starting time t
begin to an ending time t
end. Let T
=
t
1
,
t
2
,
t
3
,
…
,
t
n
t be the set of all valid time, where t
i is the ith valid time.
The valid time points out a period of time when an account is allowed to operate in a cloud platform. Time is increasing without a bound. However, an account in the cloud platform may have an expiration date or time. For instance, accounts of an enterprise that rents cloud resources for one year expire after one year. In another case, the valid time of a staff’s account ends at the day he leaves the enterprise.Definition 5 (user category).
User category is a class that a user belongs to in cloud platforms. LetC
=
c
1
,
c
2
,
c
3
,
…
,
c
n
c be the set of all categories, where c
i is the ith category.The user category makes sure to which type a user account belongs.There are various users in the cloud platform. Such users can be divided into some categories according to the user type. For example, users may be put into categories of normal user, senior user, and administrator user.


## 2.2.
4D-Role and 4D-Role Based User Group

### 2.2.1.
4D-Role

In a multitenancy cloud platform, users are divided into two categories. One is the category of tenant user. The tenant users, such as enterprise staffs, are those users who rent the cloud resources and use the cloud platform. The other is the category of platform user. The platform users operate and manage the cloud platform. Such works include assigning new resources to tenant users and managing the accounts of tenant users. So, according to Definition5 in Section 2.1, there are two user categories in our cloud platform. The set of user category is C
=
c
1
,
c
2, and c
1
=
tenant and c
2 = platform.Definition 6 (role, tenant role, and platform role).
(1) Role is a set of finite tuples formed asp
,
s
,
t
,
c. A role is represented as r
=
p
,
s
,
t
,
c, where p
∈
P
,
s
∈
S
,
t
∈
T
,
c
∈
C. Let R
=
r
1
,
r
2
,
r
3
,
…
,
r
n
r be the set of all roles, where r
i is the ith role.
(2) Letr
=
p
,
s
,
t
,
c be a role:
(a)
The roler is a tenant role, if and only if c
=
tenant.
(b)
The roler is a Platform Role, if and only if c
=
platform.From Definition 6, we can find that the role is a four-dimensional concept. A role has permissions in relevant scopes during the period of valid time. One kind of permission comprises a few basic permissions. Also, there are two types of role, tenant role and platform role.


### 2.2.2.
4D-Role Based User Group

A multitenancy cloud platform is a user operation oriented platform. There are a large number of users in a practical cloud platform, which makes user management complicated. In order to make things simpler, we could consider a group of users who have the same permissions, scopes, valid time, and user category.Definition 7 (user group, tenant user group, and platform user group).
(1) User group, which is composed of finite roles, is a set of unions of finite roles. A user group that includesk
(
m
≤
n
r
) roles is formulated as g
=
⋃
i
=
1
k
r
i
(
r
i
∈
R
). Let G
=
g
1
,
g
2
,
g
3
,
…
,
g
n
g be the set of all user groups, where g
i is the ith user group.
(2) Letg
=
⋃
i
=
1
k
r
i
(
r
i
∈
R
) be a user group.
(a)
The user groupg is a tenant user group, if and only if every r
i is a tenant role.
(b)
The user groupg is a platform user group, if and only if every r
i is a platform role.Definition 8 (tenant).
A tenant is a set of tenant user groups which are in the same enterprise. A tenant has the following properties:(1)
LetG
A be a tenant whose user groups are in the enterprise A:(1)
∀
g
m
a
=
⋃
m
i
p
k
m
i
a
,
s
n
m
i
a
,
t
l
m
i
a
,
c
h
m
i
a
∣
p
k
m
i
a
∈
P
,
s
n
m
i
a
∈
S
,
t
l
m
i
a
∈
T
,
c
h
m
i
a
=
Tenant
∈
G
A
.
(a)
The union of all permissions inG
A is P
A
=
⋃
m
⋃
m
i
p
k
m
i
a
=
⋃
j
b
j
(
a
)
⊆
B, where b
j
(
a
) is the jth basic permission in the set of all basic permissions in Tenant G
A.
(b)
The union of all scopes inG
A is S
A
=
⋃
m
⋃
m
i
s
n
m
i
a
⊆
S.
(2)
LetG
A and G
B be two tenants whose user groups are in enterprises A and B, respectively:(2)
∀
g
m
a
=
⋃
m
i
p
k
m
i
a
,
s
n
m
i
a
,
t
l
m
i
a
,
c
h
m
i
a
∣
p
k
m
i
a
∈
P
,
s
n
m
i
a
∈
S
,
t
l
m
i
a
∈
T
,
c
h
m
i
a
=
Tenant
∈
G
A
,
∀
g
m
′
b
=
⋃
m
i
′
p
k
m
i
′
b
,
s
n
m
i
′
b
,
t
l
m
i
′
b
,
c
h
m
i
′
b
∣
p
k
m
i
′
b
∈
P
,
s
n
m
i
′
b
∈
S
,
t
l
m
i
′
b
∈
T
,
c
h
m
i
′
b
=
Tenant
∈
G
B
.
G
A
=
G
B, if and only if(3)
⋃
m
⋃
m
i
p
k
m
i
a
=
⋃
m
′
⋃
m
i
′
p
k
m
i
′
b
,
⋃
m
⋃
m
i
s
n
m
i
a
=
⋃
m
′
⋃
m
i
′
s
n
m
i
′
b
,
⋃
m
⋃
m
i
t
l
m
i
a
=
⋃
m
′
⋃
m
i
′
t
l
m
i
′
b
.
(3)
LetG
1
,
G
2
…
,
G
w be w tenants in the cloud platform. Each S
i
(
1
≤
i
≤
w
) is the union of all scopes in G
i. S is the universal set of scopes in the cloud platform. The set W
=
{
S
1
,
S
2
,
…
,
S
w
,
S
-
⋃
i
=
1
w
S
i
} is a partition to S.From the definitions above, we know that the union of all permissions in a tenant has boundary. It is the same as the union of all basic permissions in the tenant. The scope in a tenant also has boundary. A partition of scopes in the cloud platform is defined to ensure that user groups in each tenant have isolated environment in operating in the cloud platform.In addition, we can find the relations among user group, role, permission, and basic permission. A user group is a set of roles, and a tenant is made up of several user groups which are in the same enterprise. As a role consists of permission, scope, valid time, and user category, in the 4D-role based multitenancy model, permissions are assigned to a user group through 4D-role. Basic permissions are able to be assigned to a user group according to the mapping from permission to basic permission. Figure2 shows the relation among user group, role, permission, and basic permission.Figure 2
Relations among user group, role, permission, and basic permission.


## 2.2.1.
4D-Role

In a multitenancy cloud platform, users are divided into two categories. One is the category of tenant user. The tenant users, such as enterprise staffs, are those users who rent the cloud resources and use the cloud platform. The other is the category of platform user. The platform users operate and manage the cloud platform. Such works include assigning new resources to tenant users and managing the accounts of tenant users. So, according to Definition5 in Section 2.1, there are two user categories in our cloud platform. The set of user category is C
=
c
1
,
c
2, and c
1
=
tenant and c
2 = platform.Definition 6 (role, tenant role, and platform role).
(1) Role is a set of finite tuples formed asp
,
s
,
t
,
c. A role is represented as r
=
p
,
s
,
t
,
c, where p
∈
P
,
s
∈
S
,
t
∈
T
,
c
∈
C. Let R
=
r
1
,
r
2
,
r
3
,
…
,
r
n
r be the set of all roles, where r
i is the ith role.
(2) Letr
=
p
,
s
,
t
,
c be a role:
(a)
The roler is a tenant role, if and only if c
=
tenant.
(b)
The roler is a Platform Role, if and only if c
=
platform.From Definition 6, we can find that the role is a four-dimensional concept. A role has permissions in relevant scopes during the period of valid time. One kind of permission comprises a few basic permissions. Also, there are two types of role, tenant role and platform role.


## 2.2.2.
4D-Role Based User Group

A multitenancy cloud platform is a user operation oriented platform. There are a large number of users in a practical cloud platform, which makes user management complicated. In order to make things simpler, we could consider a group of users who have the same permissions, scopes, valid time, and user category.Definition 7 (user group, tenant user group, and platform user group).
(1) User group, which is composed of finite roles, is a set of unions of finite roles. A user group that includesk
(
m
≤
n
r
) roles is formulated as g
=
⋃
i
=
1
k
r
i
(
r
i
∈
R
). Let G
=
g
1
,
g
2
,
g
3
,
…
,
g
n
g be the set of all user groups, where g
i is the ith user group.
(2) Letg
=
⋃
i
=
1
k
r
i
(
r
i
∈
R
) be a user group.
(a)
The user groupg is a tenant user group, if and only if every r
i is a tenant role.
(b)
The user groupg is a platform user group, if and only if every r
i is a platform role.Definition 8 (tenant).
A tenant is a set of tenant user groups which are in the same enterprise. A tenant has the following properties:(1)
LetG
A be a tenant whose user groups are in the enterprise A:(1)
∀
g
m
a
=
⋃
m
i
p
k
m
i
a
,
s
n
m
i
a
,
t
l
m
i
a
,
c
h
m
i
a
∣
p
k
m
i
a
∈
P
,
s
n
m
i
a
∈
S
,
t
l
m
i
a
∈
T
,
c
h
m
i
a
=
Tenant
∈
G
A
.
(a)
The union of all permissions inG
A is P
A
=
⋃
m
⋃
m
i
p
k
m
i
a
=
⋃
j
b
j
(
a
)
⊆
B, where b
j
(
a
) is the jth basic permission in the set of all basic permissions in Tenant G
A.
(b)
The union of all scopes inG
A is S
A
=
⋃
m
⋃
m
i
s
n
m
i
a
⊆
S.
(2)
LetG
A and G
B be two tenants whose user groups are in enterprises A and B, respectively:(2)
∀
g
m
a
=
⋃
m
i
p
k
m
i
a
,
s
n
m
i
a
,
t
l
m
i
a
,
c
h
m
i
a
∣
p
k
m
i
a
∈
P
,
s
n
m
i
a
∈
S
,
t
l
m
i
a
∈
T
,
c
h
m
i
a
=
Tenant
∈
G
A
,
∀
g
m
′
b
=
⋃
m
i
′
p
k
m
i
′
b
,
s
n
m
i
′
b
,
t
l
m
i
′
b
,
c
h
m
i
′
b
∣
p
k
m
i
′
b
∈
P
,
s
n
m
i
′
b
∈
S
,
t
l
m
i
′
b
∈
T
,
c
h
m
i
′
b
=
Tenant
∈
G
B
.
G
A
=
G
B, if and only if(3)
⋃
m
⋃
m
i
p
k
m
i
a
=
⋃
m
′
⋃
m
i
′
p
k
m
i
′
b
,
⋃
m
⋃
m
i
s
n
m
i
a
=
⋃
m
′
⋃
m
i
′
s
n
m
i
′
b
,
⋃
m
⋃
m
i
t
l
m
i
a
=
⋃
m
′
⋃
m
i
′
t
l
m
i
′
b
.
(3)
LetG
1
,
G
2
…
,
G
w be w tenants in the cloud platform. Each S
i
(
1
≤
i
≤
w
) is the union of all scopes in G
i. S is the universal set of scopes in the cloud platform. The set W
=
{
S
1
,
S
2
,
…
,
S
w
,
S
-
⋃
i
=
1
w
S
i
} is a partition to S.From the definitions above, we know that the union of all permissions in a tenant has boundary. It is the same as the union of all basic permissions in the tenant. The scope in a tenant also has boundary. A partition of scopes in the cloud platform is defined to ensure that user groups in each tenant have isolated environment in operating in the cloud platform.In addition, we can find the relations among user group, role, permission, and basic permission. A user group is a set of roles, and a tenant is made up of several user groups which are in the same enterprise. As a role consists of permission, scope, valid time, and user category, in the 4D-role based multitenancy model, permissions are assigned to a user group through 4D-role. Basic permissions are able to be assigned to a user group according to the mapping from permission to basic permission. Figure2 shows the relation among user group, role, permission, and basic permission.Figure 2
Relations among user group, role, permission, and basic permission.


## 2.3. User in the 4D-Role Based Multitenancy (4D-RBMT) Model

### 2.3.1.
4D-Role Based User

Definition 9 (user, tenant user, and platform user).
(1) User is a member of user group. A user belongs to one of user groups. LetG be the set of all user groups and let u
i
,
j be a user. ∀
g
∈
G, if u
i
,
j
∈
g
i, then u
i
,
j is called the jth user of g
i.
(2)u
i
,
j is a tenant user, if and only if g
i is a tenant user group.
(3)u
i
,
j is a platform user, if and only if g
i is a platform user group.
LetU be the set of all users: (4)
U
=
u
1
,
u
2
,
u
3
,
…
,
u
n
,where U is the number of elements in set U and u
i is the ith user.Theorem 10.
User is a union of finite roles.Proof.
LetU be the set of all users and let G be the set of all user groups.
∀
u
∈
U, ∃
g
i
∈
G, such that
u
∈
g
i.
Note that(5)
g
i
=
⋃
j
r
j
∣
r
j
∈
R
,
1
≤
j
≤
R
.Therefore (6)
u
=
⋃
j
0
r
j
0
,where r
j
0
∈
R, 1
≤
j
0
≤
R.


### 2.3.2. Hierarchy of 4D-Role Based Users

There are six types of users in a multitenancy cloud platform. Such users belong to two kinds of users: platform user and tenant user.(1) Platform user is described as follows.(
a) General Admin. It is the super administrator in the model. New applications and user categories in the cloud platform are set by the General Admin.(
b) Developer. It sets the basic permissions in the multitenancy cloud platform. There are two kinds of basic permissions in the platform. One is the kind of basic permission that is used to run programs for managing the multitenancy cloud platform. The other is the kind of basic permission that is used to run programs for managing applications in the cloud platform. The account of a developer is approved by the General Admin.(
c) Platform Senior Admin. It is responsible for configuring the permission, scope, valid time, role, and user group in the cloud platform. The highest level account, in the hierarchy of the Platform Senior Admin, is approved by a Developer. Also, a Platform Senior Admin is able to add accounts of lower level Platform Senior Admin.(
d) Platform Admin. It is the ordinary administrator to manage the cloud platform. The account of a Platform Admin is approved by a Platform Senior Admin.(2) Tenant user is described as follows.(
a) Application Administrator. It is responsible for configuring the permission, scope, valid time, role, and user group in the application system. An Application Administrator is able to add accounts of lower level Application Administrators. The highest level account, in the hierarchy of Application Administrator, is approved by a Developer.(
b) Application User. It is the terminal user to use an application.The six types of users above are divided into four levels, according to their duties in the cloud platform. General Admin is in level 1. Developer belongs to level 2. Level 3 contains Platform Senior Admin and Application Administrator. Level 4 includes Platform Admin and Application User. Figure3 shows the user hierarchy in the 4D-RBMT model.Figure 3
User hierarchy in the 4D-RBMT model.


## 2.3.1.
4D-Role Based User

Definition 9 (user, tenant user, and platform user).
(1) User is a member of user group. A user belongs to one of user groups. LetG be the set of all user groups and let u
i
,
j be a user. ∀
g
∈
G, if u
i
,
j
∈
g
i, then u
i
,
j is called the jth user of g
i.
(2)u
i
,
j is a tenant user, if and only if g
i is a tenant user group.
(3)u
i
,
j is a platform user, if and only if g
i is a platform user group.
LetU be the set of all users: (4)
U
=
u
1
,
u
2
,
u
3
,
…
,
u
n
,where U is the number of elements in set U and u
i is the ith user.Theorem 10.
User is a union of finite roles.Proof.
LetU be the set of all users and let G be the set of all user groups.
∀
u
∈
U, ∃
g
i
∈
G, such that
u
∈
g
i.
Note that(5)
g
i
=
⋃
j
r
j
∣
r
j
∈
R
,
1
≤
j
≤
R
.Therefore (6)
u
=
⋃
j
0
r
j
0
,where r
j
0
∈
R, 1
≤
j
0
≤
R.


## 2.3.2. Hierarchy of 4D-Role Based Users

There are six types of users in a multitenancy cloud platform. Such users belong to two kinds of users: platform user and tenant user.(1) Platform user is described as follows.(
a) General Admin. It is the super administrator in the model. New applications and user categories in the cloud platform are set by the General Admin.(
b) Developer. It sets the basic permissions in the multitenancy cloud platform. There are two kinds of basic permissions in the platform. One is the kind of basic permission that is used to run programs for managing the multitenancy cloud platform. The other is the kind of basic permission that is used to run programs for managing applications in the cloud platform. The account of a developer is approved by the General Admin.(
c) Platform Senior Admin. It is responsible for configuring the permission, scope, valid time, role, and user group in the cloud platform. The highest level account, in the hierarchy of the Platform Senior Admin, is approved by a Developer. Also, a Platform Senior Admin is able to add accounts of lower level Platform Senior Admin.(
d) Platform Admin. It is the ordinary administrator to manage the cloud platform. The account of a Platform Admin is approved by a Platform Senior Admin.(2) Tenant user is described as follows.(
a) Application Administrator. It is responsible for configuring the permission, scope, valid time, role, and user group in the application system. An Application Administrator is able to add accounts of lower level Application Administrators. The highest level account, in the hierarchy of Application Administrator, is approved by a Developer.(
b) Application User. It is the terminal user to use an application.The six types of users above are divided into four levels, according to their duties in the cloud platform. General Admin is in level 1. Developer belongs to level 2. Level 3 contains Platform Senior Admin and Application Administrator. Level 4 includes Platform Admin and Application User. Figure3 shows the user hierarchy in the 4D-RBMT model.Figure 3
User hierarchy in the 4D-RBMT model.


## 3. Verification of 4D-RBMT Model Using Mathematical Approaches

A cloud platform with the 4D-role based multitenancy (4D-RBMT) model has characters of independence of platform administration, isolation of tenant operation, and hierarchy of user relations. In this section, we will prove the properties in mathematics approaches. Firstly, relations between two user groups are defined.


### 3.1. User Group Relation

Definition 11 (relations between user groups).
LetG be the set of user groups, ∀
g
,
g
′
∈
G; the relation of g and g
′ is (1) disjoint, if g
∩
g
′
=
⌀, (2) inclusive, if g
⊆
g
′, and (3) mixed, if g
∩
g
′
≠
⌀, g

g
′ and g
′

g.Under the basic fact of set theory, we can find that the three relations, disjoint, inclusive, and mixed, are existing between two user groups in the 4D-RBMT model. Figure4 shows the relations of projections on the three-dimensional space composed of permission, scope, and valid time, between two user groups which have the same user categories.Figure 4
Relations of projections on the three-dimensional space composed of permission, scope, and valid time between two user groups, which have the same user categories. (a) Disjoint relation. (b) Inclusive relation. (c) Mixed relation.
(a)
(b)
(c)


### 3.2. Independence of Platform Administration

In the 4D-RBMT model based cloud platform, user groups are divided into platform user groups and tenant user groups. According to definitions in Section2, for any platform user group g
p and tenant user group g
t,(7)
g
p
=
⋃
i
=
1
k
r
i
∣
r
i
∈
R
=
⋃
i
=
1
k
p
m
i
,
s
n
i
,
t
l
i
,
c
h
i
∣
p
m
i
∈
P
,
s
n
i
∈
S
,
t
l
i
∈
T
,
c
h
i
=
Platform
,
g
t
=
⋃
j
=
1
k
′
r
j
′
∣
r
j
′
∈
R
=
⋃
j
=
1
k
′
p
m
j
′
,
s
n
i
′
,
t
l
i
′
,
c
h
i
′
∣
p
m
i
′
∈
P
,
s
n
i
′
∈
S
,
t
l
i
′
∈
T
,
c
h
i
′
=
Tenant
.Obviously, g
p
∩
g
t
=
⌀. It means that the intersection of a platform user group and a tenant user group is empty.So, the disjoint relation is the only relation between a platform user group and a tenant user group. Neither inclusive relation nor mixed relation exists between them. Moreover, operation fields of a platform user are absolutely separated from those of a tenant user. It means that a tenant user cannot operate the fields that a platform user operates. Figure5 shows the 4D-Role Based User Group’s projections on the dimension category. From the figure, we can know that a platform user group is strictly independent on a tenant user group, which means that the platform administration is independent of any tenancy application.Figure 5
User group’s projection on the dimension category.


### 3.3. Isolation of Tenant Operation

In the 4D-RBMT model, operation field of user groups in a tenant is strictly isolated from that in another different tenant. It is attributed to the fact that two user groups which belong to different tenants have disjoint relation only, which means that the two user groups have an empty intersection. Theorem12 below proves it.Theorem 12.
LetG
A and G
B be two tenants whose user groups are in enterprises A and B, respectively. ∀
g
m
(
a
)
∈
G
A, ∀
g
m
′
(
b
)
∈
G
B, if G
A
≠
G
B, then g
m
(
a
)
∩
g
m
′
(
b
)
=
⌀.Proof.
A method of proof by contradiction is used to prove the theorem.
Suppose that∃
g
m
(
a
)
∈
G
A, g
m
′
(
b
)
∈
G
B, such that g
m
(
a
)
∩
g
m
′
(
b
)
≠
⌀, where(8)
g
m
a
=
⋃
m
i
p
k
m
i
a
,
s
n
m
i
a
,
t
l
m
i
a
,
c
h
m
i
a
∣
p
k
m
i
a
∈
P
,
s
n
m
i
a
∈
S
,
t
l
m
i
a
∈
T
,
c
h
m
i
a
=
Tenant
,
g
m
′
b
=
⋃
m
i
′
p
k
m
i
′
b
,
s
n
m
i
′
b
,
t
l
m
i
′
b
,
c
h
m
i
′
b
∣
p
k
m
i
′
b
∈
P
,
s
n
m
i
′
b
∈
S
,
t
l
m
i
′
b
∈
T
,
c
h
m
i
′
b
=
Tenantthat means ∃
r
0
=
p
0
,
s
0
,
t
0
,
Tenant, such that g
m
(
a
)
∩
g
m
′
b
=
r
0.
Thus(9)
s
0
∈
s
n
m
i
a
∩
s
n
m
i
′
b
.It implies that(10)
s
0
∈
⋃
m
⋃
m
i
s
n
m
i
a
∩
⋃
m
′
⋃
m
i
′
s
n
m
i
′
b
.
S
1
=
(
⋃
m
(
⋃
m
i
s
n
m
i
(
a
)
)
) is the scope of G
A and S
2
=
(
⋃
m
′
(
⋃
m
i
′
s
n
m
i
′
(
b
)
)
) is the scope of G
B.
SinceG
A
≠
G
B, according to Definition 8, the set W
=
{
S
1
,
S
2
,
…
,
S
w
,
S
-
⋃
i
=
1
w
S
i
} is a partition to S, where S is the universal set of scopes in the cloud platform.
So,(11)
S
1
∩
S
2
=
⌀
.We know that(12)
⋃
m
⋃
m
i
s
n
m
i
a
∩
⋃
m
′
⋃
m
i
′
s
n
m
i
′
b
=
⌀
.At this time, there is a contradiction between (10) and (12), which means that the hypothesis g
m
(
a
)
∩
g
m
′
(
b
)
≠
⌀ is false.
Thus,g
m
(
a
)
∩
g
m
′
(
b
)
=
⌀.Theorem12 proves that the 4D-RBMT model has a character of tenant isolation. Figure 6 shows the 4D-Role Based User Group’s projections to the three-dimensional space composed of permission, scope, and valid time. From the figure, we can find that two user groups which belong to two different tenants only have the relation of disjoint, which means that user groups in one tenant are absolutely isolated from any user groups in another tenant.Figure 6
User group’s projection on the three-dimensional space composed of permission, scope, and valid time.


### 3.4. Hierarchy of User Relations

In Section3.1, we have known that there are three relations existing between user groups, such as disjoint relation, inclusive relation, and mixed relation. Moreover, in the two user groups which are inclusive, the permissions, scopes, and valid time of the subgroup are not more than those of supergroup, and the two categories are the same.Theorem 13.
LetG be the set of user groups, ∀
g
,
g
′
∈
G; if g
⊆
g
′, then P
⊆
P
′, S
⊆
S
′, T
⊆
T
′, and c
k
i
=
c
k
j
′, where P and P
′ are the permissions of g and g
′, S and S
′ are the scopes of g and g
′, T and T
′ are the valid time of g and g
′, and c
k and c
k
′ are the categories of g and g
′, respectively.Proof.
Consider∀
g
,
g
′
∈
G:(13)
g
=
⋃
i
r
i
∣
r
i
∈
R
,
1
≤
i
≤
R
,
g
′
=
⋃
j
r
j
′
∣
r
j
′
∈
R
′
,
1
≤
j
≤
R
′
.Since g
⊆
g
′, so that ∀
1
≤
i
≤
R, ∃
1
≤
j
i
≤
R
′, we have r
j
i
′
=
r
i.
Note that(14)
r
i
=
p
i
,
s
i
,
t
i
,
c
k
i
∣
p
i
∈
P
,
s
i
∈
S
,
t
i
∈
T
,
1
≤
i
≤
P
,
c
k
i
∈
C
,
r
j
i
′
=
p
j
i
′
,
s
j
i
′
,
t
j
i
′
,
c
k
j
i
′
∣
p
j
i
′
∈
P
′
,
s
j
i
′
∈
S
′
,
t
j
i
′
∈
T
′
,
1
≤
j
i
≤
P
′
,
c
k
j
i
′
∈
C
.This implies that (15)
p
j
i
′
,
s
j
i
′
,
t
j
i
′
,
c
k
j
i
′
=
p
i
,
s
i
,
t
i
,
c
k
i
.Therefore ∀
1
≤
i
≤
R, ∃
1
≤
j
i
≤
R
′, such  that
p
j
i
′
=
p
i, s
j
i
′
=
s
i, and t
j
i
′
=
t
i.
Alsoc
k
i
=
c
k
j
i
′.
SoP
⊆
P
′, S
⊆
S
′, and T
⊆
T
′.
Now we provec
k
i
=
c
k
j
i
′.
Sinceg, g
′ are two nonempty user groups, and g
⊆
g
′, it means that g
∩
g
′
≠
⌀.
Ifc
k
i
≠
c
k
j
i
′, that means, in the two user groups g, g
′, one is tenant user group and the other is platform user group. According to the independent property introduced in Section 3.2, we know that g
∩
g
′
=
⌀. It is a contradiction against the fact g
∩
g
′
≠
⌀.
Thus,P
⊆
P
′, S
⊆
S
′, T
⊆
T
′, and c
k
i
=
c
k
j
i
′.Theorem13 above indicates that if two user groups are inclusive, the permissions, scopes, and valid time of the two user groups also have inclusive relations.


## 3.1. User Group Relation

Definition 11 (relations between user groups).
LetG be the set of user groups, ∀
g
,
g
′
∈
G; the relation of g and g
′ is (1) disjoint, if g
∩
g
′
=
⌀, (2) inclusive, if g
⊆
g
′, and (3) mixed, if g
∩
g
′
≠
⌀, g

g
′ and g
′

g.Under the basic fact of set theory, we can find that the three relations, disjoint, inclusive, and mixed, are existing between two user groups in the 4D-RBMT model. Figure4 shows the relations of projections on the three-dimensional space composed of permission, scope, and valid time, between two user groups which have the same user categories.Figure 4
Relations of projections on the three-dimensional space composed of permission, scope, and valid time between two user groups, which have the same user categories. (a) Disjoint relation. (b) Inclusive relation. (c) Mixed relation.
(a)
(b)
(c)


## 3.2. Independence of Platform Administration

In the 4D-RBMT model based cloud platform, user groups are divided into platform user groups and tenant user groups. According to definitions in Section2, for any platform user group g
p and tenant user group g
t,(7)
g
p
=
⋃
i
=
1
k
r
i
∣
r
i
∈
R
=
⋃
i
=
1
k
p
m
i
,
s
n
i
,
t
l
i
,
c
h
i
∣
p
m
i
∈
P
,
s
n
i
∈
S
,
t
l
i
∈
T
,
c
h
i
=
Platform
,
g
t
=
⋃
j
=
1
k
′
r
j
′
∣
r
j
′
∈
R
=
⋃
j
=
1
k
′
p
m
j
′
,
s
n
i
′
,
t
l
i
′
,
c
h
i
′
∣
p
m
i
′
∈
P
,
s
n
i
′
∈
S
,
t
l
i
′
∈
T
,
c
h
i
′
=
Tenant
.Obviously, g
p
∩
g
t
=
⌀. It means that the intersection of a platform user group and a tenant user group is empty.So, the disjoint relation is the only relation between a platform user group and a tenant user group. Neither inclusive relation nor mixed relation exists between them. Moreover, operation fields of a platform user are absolutely separated from those of a tenant user. It means that a tenant user cannot operate the fields that a platform user operates. Figure5 shows the 4D-Role Based User Group’s projections on the dimension category. From the figure, we can know that a platform user group is strictly independent on a tenant user group, which means that the platform administration is independent of any tenancy application.Figure 5
User group’s projection on the dimension category.


## 3.3. Isolation of Tenant Operation

In the 4D-RBMT model, operation field of user groups in a tenant is strictly isolated from that in another different tenant. It is attributed to the fact that two user groups which belong to different tenants have disjoint relation only, which means that the two user groups have an empty intersection. Theorem12 below proves it.Theorem 12.
LetG
A and G
B be two tenants whose user groups are in enterprises A and B, respectively. ∀
g
m
(
a
)
∈
G
A, ∀
g
m
′
(
b
)
∈
G
B, if G
A
≠
G
B, then g
m
(
a
)
∩
g
m
′
(
b
)
=
⌀.Proof.
A method of proof by contradiction is used to prove the theorem.
Suppose that∃
g
m
(
a
)
∈
G
A, g
m
′
(
b
)
∈
G
B, such that g
m
(
a
)
∩
g
m
′
(
b
)
≠
⌀, where(8)
g
m
a
=
⋃
m
i
p
k
m
i
a
,
s
n
m
i
a
,
t
l
m
i
a
,
c
h
m
i
a
∣
p
k
m
i
a
∈
P
,
s
n
m
i
a
∈
S
,
t
l
m
i
a
∈
T
,
c
h
m
i
a
=
Tenant
,
g
m
′
b
=
⋃
m
i
′
p
k
m
i
′
b
,
s
n
m
i
′
b
,
t
l
m
i
′
b
,
c
h
m
i
′
b
∣
p
k
m
i
′
b
∈
P
,
s
n
m
i
′
b
∈
S
,
t
l
m
i
′
b
∈
T
,
c
h
m
i
′
b
=
Tenantthat means ∃
r
0
=
p
0
,
s
0
,
t
0
,
Tenant, such that g
m
(
a
)
∩
g
m
′
b
=
r
0.
Thus(9)
s
0
∈
s
n
m
i
a
∩
s
n
m
i
′
b
.It implies that(10)
s
0
∈
⋃
m
⋃
m
i
s
n
m
i
a
∩
⋃
m
′
⋃
m
i
′
s
n
m
i
′
b
.
S
1
=
(
⋃
m
(
⋃
m
i
s
n
m
i
(
a
)
)
) is the scope of G
A and S
2
=
(
⋃
m
′
(
⋃
m
i
′
s
n
m
i
′
(
b
)
)
) is the scope of G
B.
SinceG
A
≠
G
B, according to Definition 8, the set W
=
{
S
1
,
S
2
,
…
,
S
w
,
S
-
⋃
i
=
1
w
S
i
} is a partition to S, where S is the universal set of scopes in the cloud platform.
So,(11)
S
1
∩
S
2
=
⌀
.We know that(12)
⋃
m
⋃
m
i
s
n
m
i
a
∩
⋃
m
′
⋃
m
i
′
s
n
m
i
′
b
=
⌀
.At this time, there is a contradiction between (10) and (12), which means that the hypothesis g
m
(
a
)
∩
g
m
′
(
b
)
≠
⌀ is false.
Thus,g
m
(
a
)
∩
g
m
′
(
b
)
=
⌀.Theorem12 proves that the 4D-RBMT model has a character of tenant isolation. Figure 6 shows the 4D-Role Based User Group’s projections to the three-dimensional space composed of permission, scope, and valid time. From the figure, we can find that two user groups which belong to two different tenants only have the relation of disjoint, which means that user groups in one tenant are absolutely isolated from any user groups in another tenant.Figure 6
User group’s projection on the three-dimensional space composed of permission, scope, and valid time.


## 3.4. Hierarchy of User Relations

In Section3.1, we have known that there are three relations existing between user groups, such as disjoint relation, inclusive relation, and mixed relation. Moreover, in the two user groups which are inclusive, the permissions, scopes, and valid time of the subgroup are not more than those of supergroup, and the two categories are the same.Theorem 13.
LetG be the set of user groups, ∀
g
,
g
′
∈
G; if g
⊆
g
′, then P
⊆
P
′, S
⊆
S
′, T
⊆
T
′, and c
k
i
=
c
k
j
′, where P and P
′ are the permissions of g and g
′, S and S
′ are the scopes of g and g
′, T and T
′ are the valid time of g and g
′, and c
k and c
k
′ are the categories of g and g
′, respectively.Proof.
Consider∀
g
,
g
′
∈
G:(13)
g
=
⋃
i
r
i
∣
r
i
∈
R
,
1
≤
i
≤
R
,
g
′
=
⋃
j
r
j
′
∣
r
j
′
∈
R
′
,
1
≤
j
≤
R
′
.Since g
⊆
g
′, so that ∀
1
≤
i
≤
R, ∃
1
≤
j
i
≤
R
′, we have r
j
i
′
=
r
i.
Note that(14)
r
i
=
p
i
,
s
i
,
t
i
,
c
k
i
∣
p
i
∈
P
,
s
i
∈
S
,
t
i
∈
T
,
1
≤
i
≤
P
,
c
k
i
∈
C
,
r
j
i
′
=
p
j
i
′
,
s
j
i
′
,
t
j
i
′
,
c
k
j
i
′
∣
p
j
i
′
∈
P
′
,
s
j
i
′
∈
S
′
,
t
j
i
′
∈
T
′
,
1
≤
j
i
≤
P
′
,
c
k
j
i
′
∈
C
.This implies that (15)
p
j
i
′
,
s
j
i
′
,
t
j
i
′
,
c
k
j
i
′
=
p
i
,
s
i
,
t
i
,
c
k
i
.Therefore ∀
1
≤
i
≤
R, ∃
1
≤
j
i
≤
R
′, such  that
p
j
i
′
=
p
i, s
j
i
′
=
s
i, and t
j
i
′
=
t
i.
Alsoc
k
i
=
c
k
j
i
′.
SoP
⊆
P
′, S
⊆
S
′, and T
⊆
T
′.
Now we provec
k
i
=
c
k
j
i
′.
Sinceg, g
′ are two nonempty user groups, and g
⊆
g
′, it means that g
∩
g
′
≠
⌀.
Ifc
k
i
≠
c
k
j
i
′, that means, in the two user groups g, g
′, one is tenant user group and the other is platform user group. According to the independent property introduced in Section 3.2, we know that g
∩
g
′
=
⌀. It is a contradiction against the fact g
∩
g
′
≠
⌀.
Thus,P
⊆
P
′, S
⊆
S
′, T
⊆
T
′, and c
k
i
=
c
k
j
i
′.Theorem13 above indicates that if two user groups are inclusive, the permissions, scopes, and valid time of the two user groups also have inclusive relations.


## 4. Performance Evaluations

For demonstrating our proposed 4D-RBMT model, we firstly implement a prototype system considering typical enterprise operations that are running in multitenancy cloud environment. The proposed prototype system is developed using Java language. With Spring MVC framework, it is convenient to provide necessary APIs which can be visited by other systems. Then, hotel and restaurant business are separately running in the multitenancy platform provided by a cloud provider, which is used to evaluate the characters of platform administration independence, role hierarchy, and tenant isolation in the 4D-RBMT model. Last, performance of the prototype system using cloud resources is evaluated.The experiments are conducted on a Vmware Cloud environment. The computer resources consist of 20 VMware-server virtual machines (each has 2 GB memory and runs CentOS7) hosted on two vSphere servers with dual 2.6 GHz Xeon CPU and 96 GB memory. Each virtual machine is one of the tenants in the cloud. The prototype system is deployed on every virtual machine and provides remote access through APIs relative to roles.


### 4.1. Introduction to the Prototype System

#### 4.1.1. System Structure of the Prototype System

There are four modules in the 4D-RBMT model, 4D-Role Based Power Configuration Module (4D-Role PCM), User Account Module (UAM), Power Validation Module (PVM), and Apply and Permit Interface (API). In the structure, 4D-Role PCM and UAM are communicated through the API, which is supported by the PVM. Figure7 is the structure of the 4D-RBMT model.Figure 7
Structure of the 4D-RBMT model.4D-Role PCM is the key module in the 4D-RBMT model. It deals with the operation of power configuration management, which involves the power configurations, such as Basic Permission Configuration (BPC), Permission Configuration (PC), Role Configuration (RC), and User Group Configuration (UGC).In BPC, a basic permission is one of the operations in adding, deleting, and updating. The configuration of basic permission in BPC is operated by a system operator (SYSOP). In PC, permission is a union of finite basic permissions. Fetched from BPC, basic permissions are combined for certain requirements of the business applications. In RC, role is a set of finite four-dimensional vectors composed of permissions, scopes, valid time, and user categories. Obtained from AC, an authority is matched with a scope and permission time for certain requirements of the business. In UGC, user group is a set of unions of finite roles. Obtained from RC, roles are combined for certain requirements.The User Account Module (UAM) contains the operation that users register to get accounts and update their personal information. Also, user information can be imported from or exported to files. Finally, every user belongs to a user group which is configured in the Power Configuration Module (PCM).Power application and power permission are two key operations in Power Validation Module (PVM). A user previously applies for joining in a user group through operation of power application. An administrator permits a user’s application to join in a user group after verifying the information of the applicant through operation of power permission. In addition, an administrator can remove a user from any user group.Apply and Permit Interface (API), supported by the PVM, is an interface connecting UAM and PCM.


#### 4.1.2. Workflow of 4D-Role Based User Assignment

As we know, users in the 4D-RBMT model have six types. Users in different types have their own duties in the model. The General Admin works at setting cloud application and user categories. A developer is responsible for setting basic permissions. Platform user groups and tenant user groups are configured by Platform Senior Admin and Application Administrator, respectively. A Platform Admin or an Application User needs to register first and then be assigned to a user group. Figure8 shows the workflow of user group configuration and assignment in the 4D-RBMT model.Figure 8
Workflow of the 4D-RBMT model.


### 4.2. Experimental Evaluation of Performance in Business Functions

#### 4.2.1. Business Functions

(a) User Functions.Functions of each user in the prototype are listed in Table 1. Depending on the defined users and functions, a user graph describing the structural relations among the users is shown in Figure 9.Table 1
Users and functions.
Number
User
User type
Functions
U
1
General Admin
General Admin
Set applications and user categories
U
2
Application Developer
Developer
Set basic permissions of applications
U
3
Platform Developer
Developer
Set basic permissions of the platform
U
4
Cloud platform manager
Platform Senior Admin
Manage cloud resource lease affairs for all the enterprises
U
5
Manager of admin  for  manufacture enterprises
Platform Senior Admin
Manage cloud resource lease affairs for manufacture enterprises
U
6
Manager of admin  for service enterprises
Platform Senior Admin
Manage cloud resource lease affairs for service enterprises
U
7
Admin of hotel enterprises
Platform Admin
Manage cloud resource lease affairs for hotel enterprises
U
8
Admin of restaurant enterprises
Platform Admin
Manage cloud resource lease affairs for restaurant enterprises
U
9
General Manger (hotel)
Application Administrator
Manage all the affairs in the hotel and approve management report
U
10
Manager of room division
Application Administrator
Manage room affairs and submit room management report
U
11
Room receptionist
Application User
Manage room reception affairs
U
12
Room attendant
Application User
Manage room service affairs
U
13
Manager of finance (hotel)
Application Administrator
Manage finance affairs and submit finance management report
U
14
Accountant (hotel)
Application User
Manage hotel accounting affairs
U
15
Cashier (hotel)
Application User
Manage hotel cashier affairs
U
16
General Manager (restaurant)
Application Administrator
Manage all the affairs in the restaurant and approve management report
U
17
Manager of Food and Beverage
Application Administrator
Manage food and beverage affairs and submit food and beverage management report
U
18
Food attendant
Application User
Manage food affairs
U
19
Beverage attendant
Application User
Manage beverage affairs
U
20
Manager of Finance (restaurant)
Application Administrator
Manage finance affairs and submit finance report
U
21
Accountant (restaurant)
Application User
Manage accounting affairs
U
22
Cashier (restaurant)
Application User
Manage cashier affairsFigure 9
A user graph describing the structural relations among the users.(b) Configuration of 4D-Role Based User.As the 4D-role in the 4D-RBMT model is composed of permission, scope, valid time, and user category, we configure the four elements of 4D-Role starting with the configuration of basic permission, while permission is a union of one or more basic permissions.We consider three types of basic permissions (BP) in the prototype. The first type is the management of information, including create, delete, update, and view on the conventional data items. The second type is related to the affairs about management report, which is composed of basic permission of submit and approve management reports. The third type which consists of assigning cloud resource and repossessing cloud resource is something about the management of cloud resource. Table2 shows the basic permissions and permissions in our prototype. Scopes are also configured and listed in Table 3. Relations existing among those scopes are also listed.Table 2
Basic permissions and permissions.
Basic permission number
Basic permission
Permission number
Permission
BP1
Create information
P
1
P
1 = BP1 ∪ BP2 ∪ BP3 ∪ BP4
BP2
Delete information
BP3
Update information
BP4
View information
BP5
Submit management report
P
2
P
2 = BP5
BP6
Approve management report
P
3
P
3 = BP6
BP7
Assign cloud resource
P
4
P
4 = BP7 ∪ BP8
BP8
Repossess cloud resourceTable 3
Scopes and relations.
Scope number
Scope
Scope relations
S
1
Cloud resource lease affairs for all the enterprises
S
1
⊃
(
2
∪
S
3
)
S
2
Cloud resource lease affairs for manufacture enterprises
S
3
Cloud resource lease affairs for service enterprises
S
3
=
S
4
∪
S
5
S
4
Cloud resource lease affairs for hotel enterprises
S
5
Cloud resource lease affairs for restaurant enterprises
S
6
Hotel affairs
S
6
⊃
(
7
∪
S
10
)
S
7
Hotel room affairs
S
7
=
S
8
∪
S
9
S
8
Hotel room reception affairs
S
9
Hotel room service affairs
S
10
Hotel finance affairs
S
10
=
S
11
∪
S
12
S
11
Hotel accounting affairs
S
12
Hotel cashier affairs
S
13
Restaurant affairs
S
13
⊃
(
14
∪
S
17
)
S
14
Food and beverage affairs
S
14
=
S
15
∪
S
16
S
15
Food affairs
S
16
Beverage affairs
S
17
Restaurant finance affairs
S
17
=
S
18
∪
S
19
S
18
Restaurant accounting affairs
S
19
Restaurant cashier affairsBesides the permissions and scopes, in our 4D-role concept, user category and valid time are needed to be considered. Platform and tenant are two categories in the prototype. To make system simpler, every valid time ranges from −∞ to ∞.


#### 4.2.2. Evaluation Results

After configuring permissions, scopes, valid time, and user categories as mentioned in Section4.2, we run the hotel and restaurant business in the prototype implemented in Section 4.1. We examine fields of user duties and find the boundaries of the fields. The users include the ones from both platform and tenants. Figure 10 shows the fields of user duties.Figure 10
Fields of user duties.In the figure, there are four platform users,U
4, U
5, U
7, and U
8. The user type of U
4, U
5, and U
7 is Platform Senior Admin, while the user type of U
8 is Platform Admin. On the other side, U
10, U
14, U
15, U
17, U
21, and U
22 are from two tenants. We can find from the figure that the fields of platform user are absolutely different from those of users from the two tenants. It indicates that the platform users have no rights to operate any data items in the tenants. The duties of platform users to the tenants are only operating the cloud resources such as assigning resources and repossessing resources. Moreover, the figure illustrates that the platform has an independent administration environment. It means that the administration never depends on applications or enterprises of tenant.Next, we verify the character of user hierarchy using the prototype. Figure11 shows the hierarchy structures of the users, no matter what user types they belong to.Figure 11
Hierarchy structure of the users. (a) Three users from the cloud platform. (b) Three users from the hotel tenant. (c) Three users from the restaurant tenant.
(a)
(b)
(c)In Figure11(a), the fields of the three users, U
4, U
5, and U
7, have a relation U
4
⊃
U
5
⊃
U
7. It means that the three users build a hierarchy structure. It is attributed to the fact that the corresponding scopes of the three users have relation that S
1
⊃
S
4
⊃
S
5, while the permissions of three users are the same. In Figure 11(b), there is a relation, U
9
⊃
U
13
⊃
U
14, existing in the fields of the three users U
9, U
13, and U
14. The reasons of becoming such hierarchy structure are from two aspects. On one hand, the permissions of the three users are P
1
∪
P
2
∪
P
3, P
1
∪
P
2, and P
1, respectively, which is an inclusive relation. On the other hand, scopes of the three users have inclusive relations that S
6
⊃
S
10
⊃
S
11. The same as U
9, U
13, and U
14 in Figure 11(b), in Figure 11(c), the users U
21, U
20, and U
16 become a hierarchy structure.Lastly, we compare the fields of the two tenants. Figure12 shows the fields of the hotel tenant and the restaurant tenant.Figure 12
Fields of the two tenants.Figure12 illustrates that there is no intersection between the fields of users U
9 and U
16. From the hierarchy structures shown in Figure 11, we can know that U
9 and U
16 have the largest fields in their own tenants. It infers that the two tenants are totally isolated. So, the character of tenant isolation is verified.


### 4.3. Simulation Evaluation of Performance in Using Cloud Resources

It is significant to evaluate the performance of the prototype system in using cloud resources, especially in the cases when a lot of users are using the cloud platform simultaneously. Simulations that simulate behaviors of large-scale users are used to evaluate the performance.


#### 4.3.1. Simulation Parameters

We use simulations to evaluate the performance of our proposed prototype in using cloud resources. In the simulations, performance of tenant systems and cloud platform is evaluated under different loads. The parameters of the simulations that simulate different scenarios include number of users, max number of concurrent users, and runtime. Table4 shows the details of parameters in the simulations.Table 4
Simulation parameters.
Parameter
Value
Description
Number of users
2500, 5000, 7500, 10000, 12500, 15000, 17500, 20000
The number of users in simulation
Max number of concurrent users
400–1000
The max number of concurrent users in simulation
Runtime
30 s–60 s
The runtime of simulationIn the evaluation, CPU usage and active memory are used to measure the running status of the tenant system and cloud platform. Besides CPU usage and active memory, response time is used to evaluate the system efficiency of our proposed system. There are three kinds of response time that are used to measure the performance. First one is average response time. It reflects the average experience of users. Next, max response time describes the worst case in using this prototype system. Last, line of 99% response time is the value of top 99% shortest response time in simulation, which gives the upper bound of most cases in using this prototype system.


#### 4.3.2. Evaluation Results

Three rounds of simulations are run under light, normal, and heavy loads. After that, we analyze the data collected from vSphere monitor and evaluate the performance. Figure13 shows the CPU usage and active memory of one of the tenant systems and the cloud platform.Figure 13
CPU usage and active memory in the simulation. (a) CPU usage of cloud platform. (b) Active memory of cloud platform. (c) CPU usage of tenant system. (d) Active memory of tenant system.
(a)
(b)
(c)
(d)Figure13 illustrates that the max value of CPU usage and active memory, in both tenant and cloud platform, is growing with the increase of user number. The usage of CPU in the environment of light load reaches the peak of 22.08% for a tenant and 34.97% for the whole cloud platform. In the scenario of running under the normal load, the maximum of the CPU usage for the tenant and cloud platform is 25.05% and 43.43%, respectively. In the heavy load situation, the usage of CPU increases up to 37.9% for tenant and 48.92% for the cloud platform. Under the heavy load, the value for tenant increases to 51.3% compared with the environment under the normal load and 71.6% compared with that under the light load. Meanwhile, the increase ratios of CPU usage for cloud platform under the heavy load are 12.6% and 39.9%, compared to the situations under the normal and light loads. This indicates that the CPU usage for a cloud platform increases slower than that for a tenant. As for active memory, it has almost the same trend as the CPU usage.In addition, we evaluate the response time that indicates how long an authorization query is answered. Figure14 shows the response time in the simulation.Figure 14
Response time in the simulation. (a) Average response time. (b) Line of 99% response time. (c) Max response time.
(a)
(b)
(c)The number of users in simulations ranges from 2500 to 20000. According to Figure14, the average response time is increasing almost linearly and the line of 99% response time is also increasing smoothly. It indicates that the proposed system can keep a low latency performance in most of the scenarios. As for the max response time, the proposed system has an acceptable performance in these kinds of extreme situations, which appear at a quite low probability.The evaluation results above imply that our proposed system performed well in situations where large-scale users are operating in the cloud platform. Our proposed system can deal with the surge of user number with limited cloud resource. Meanwhile, it is able to provide high quality and low response service for most of the users.The experimental evaluation in Section4.2 shows that the 4D-RBMT model is business-oriented model for multitenant users in cloud platform. It is suitable not only for different enterprises as tenants to configure and manage users’ roles in cloud, but also for administrators of cloud providers to assign resources to the tenants and manage tenants’ role in the cloud. According to the evaluation in Section 4.3, the proposed system performed well in the situations of large amount of users who are operating in the cloud simultaneously.


## 4.1. Introduction to the Prototype System

### 4.1.1. System Structure of the Prototype System

There are four modules in the 4D-RBMT model, 4D-Role Based Power Configuration Module (4D-Role PCM), User Account Module (UAM), Power Validation Module (PVM), and Apply and Permit Interface (API). In the structure, 4D-Role PCM and UAM are communicated through the API, which is supported by the PVM. Figure7 is the structure of the 4D-RBMT model.Figure 7
Structure of the 4D-RBMT model.4D-Role PCM is the key module in the 4D-RBMT model. It deals with the operation of power configuration management, which involves the power configurations, such as Basic Permission Configuration (BPC), Permission Configuration (PC), Role Configuration (RC), and User Group Configuration (UGC).In BPC, a basic permission is one of the operations in adding, deleting, and updating. The configuration of basic permission in BPC is operated by a system operator (SYSOP). In PC, permission is a union of finite basic permissions. Fetched from BPC, basic permissions are combined for certain requirements of the business applications. In RC, role is a set of finite four-dimensional vectors composed of permissions, scopes, valid time, and user categories. Obtained from AC, an authority is matched with a scope and permission time for certain requirements of the business. In UGC, user group is a set of unions of finite roles. Obtained from RC, roles are combined for certain requirements.The User Account Module (UAM) contains the operation that users register to get accounts and update their personal information. Also, user information can be imported from or exported to files. Finally, every user belongs to a user group which is configured in the Power Configuration Module (PCM).Power application and power permission are two key operations in Power Validation Module (PVM). A user previously applies for joining in a user group through operation of power application. An administrator permits a user’s application to join in a user group after verifying the information of the applicant through operation of power permission. In addition, an administrator can remove a user from any user group.Apply and Permit Interface (API), supported by the PVM, is an interface connecting UAM and PCM.


### 4.1.2. Workflow of 4D-Role Based User Assignment

As we know, users in the 4D-RBMT model have six types. Users in different types have their own duties in the model. The General Admin works at setting cloud application and user categories. A developer is responsible for setting basic permissions. Platform user groups and tenant user groups are configured by Platform Senior Admin and Application Administrator, respectively. A Platform Admin or an Application User needs to register first and then be assigned to a user group. Figure8 shows the workflow of user group configuration and assignment in the 4D-RBMT model.Figure 8
Workflow of the 4D-RBMT model.


## 4.1.1. System Structure of the Prototype System

There are four modules in the 4D-RBMT model, 4D-Role Based Power Configuration Module (4D-Role PCM), User Account Module (UAM), Power Validation Module (PVM), and Apply and Permit Interface (API). In the structure, 4D-Role PCM and UAM are communicated through the API, which is supported by the PVM. Figure7 is the structure of the 4D-RBMT model.Figure 7
Structure of the 4D-RBMT model.4D-Role PCM is the key module in the 4D-RBMT model. It deals with the operation of power configuration management, which involves the power configurations, such as Basic Permission Configuration (BPC), Permission Configuration (PC), Role Configuration (RC), and User Group Configuration (UGC).In BPC, a basic permission is one of the operations in adding, deleting, and updating. The configuration of basic permission in BPC is operated by a system operator (SYSOP). In PC, permission is a union of finite basic permissions. Fetched from BPC, basic permissions are combined for certain requirements of the business applications. In RC, role is a set of finite four-dimensional vectors composed of permissions, scopes, valid time, and user categories. Obtained from AC, an authority is matched with a scope and permission time for certain requirements of the business. In UGC, user group is a set of unions of finite roles. Obtained from RC, roles are combined for certain requirements.The User Account Module (UAM) contains the operation that users register to get accounts and update their personal information. Also, user information can be imported from or exported to files. Finally, every user belongs to a user group which is configured in the Power Configuration Module (PCM).Power application and power permission are two key operations in Power Validation Module (PVM). A user previously applies for joining in a user group through operation of power application. An administrator permits a user’s application to join in a user group after verifying the information of the applicant through operation of power permission. In addition, an administrator can remove a user from any user group.Apply and Permit Interface (API), supported by the PVM, is an interface connecting UAM and PCM.


## 4.1.2. Workflow of 4D-Role Based User Assignment

As we know, users in the 4D-RBMT model have six types. Users in different types have their own duties in the model. The General Admin works at setting cloud application and user categories. A developer is responsible for setting basic permissions. Platform user groups and tenant user groups are configured by Platform Senior Admin and Application Administrator, respectively. A Platform Admin or an Application User needs to register first and then be assigned to a user group. Figure8 shows the workflow of user group configuration and assignment in the 4D-RBMT model.Figure 8
Workflow of the 4D-RBMT model.


## 4.2. Experimental Evaluation of Performance in Business Functions

### 4.2.1. Business Functions

(a) User Functions.Functions of each user in the prototype are listed in Table 1. Depending on the defined users and functions, a user graph describing the structural relations among the users is shown in Figure 9.Table 1
Users and functions.
Number
User
User type
Functions
U
1
General Admin
General Admin
Set applications and user categories
U
2
Application Developer
Developer
Set basic permissions of applications
U
3
Platform Developer
Developer
Set basic permissions of the platform
U
4
Cloud platform manager
Platform Senior Admin
Manage cloud resource lease affairs for all the enterprises
U
5
Manager of admin  for  manufacture enterprises
Platform Senior Admin
Manage cloud resource lease affairs for manufacture enterprises
U
6
Manager of admin  for service enterprises
Platform Senior Admin
Manage cloud resource lease affairs for service enterprises
U
7
Admin of hotel enterprises
Platform Admin
Manage cloud resource lease affairs for hotel enterprises
U
8
Admin of restaurant enterprises
Platform Admin
Manage cloud resource lease affairs for restaurant enterprises
U
9
General Manger (hotel)
Application Administrator
Manage all the affairs in the hotel and approve management report
U
10
Manager of room division
Application Administrator
Manage room affairs and submit room management report
U
11
Room receptionist
Application User
Manage room reception affairs
U
12
Room attendant
Application User
Manage room service affairs
U
13
Manager of finance (hotel)
Application Administrator
Manage finance affairs and submit finance management report
U
14
Accountant (hotel)
Application User
Manage hotel accounting affairs
U
15
Cashier (hotel)
Application User
Manage hotel cashier affairs
U
16
General Manager (restaurant)
Application Administrator
Manage all the affairs in the restaurant and approve management report
U
17
Manager of Food and Beverage
Application Administrator
Manage food and beverage affairs and submit food and beverage management report
U
18
Food attendant
Application User
Manage food affairs
U
19
Beverage attendant
Application User
Manage beverage affairs
U
20
Manager of Finance (restaurant)
Application Administrator
Manage finance affairs and submit finance report
U
21
Accountant (restaurant)
Application User
Manage accounting affairs
U
22
Cashier (restaurant)
Application User
Manage cashier affairsFigure 9
A user graph describing the structural relations among the users.(b) Configuration of 4D-Role Based User.As the 4D-role in the 4D-RBMT model is composed of permission, scope, valid time, and user category, we configure the four elements of 4D-Role starting with the configuration of basic permission, while permission is a union of one or more basic permissions.We consider three types of basic permissions (BP) in the prototype. The first type is the management of information, including create, delete, update, and view on the conventional data items. The second type is related to the affairs about management report, which is composed of basic permission of submit and approve management reports. The third type which consists of assigning cloud resource and repossessing cloud resource is something about the management of cloud resource. Table2 shows the basic permissions and permissions in our prototype. Scopes are also configured and listed in Table 3. Relations existing among those scopes are also listed.Table 2
Basic permissions and permissions.
Basic permission number
Basic permission
Permission number
Permission
BP1
Create information
P
1
P
1 = BP1 ∪ BP2 ∪ BP3 ∪ BP4
BP2
Delete information
BP3
Update information
BP4
View information
BP5
Submit management report
P
2
P
2 = BP5
BP6
Approve management report
P
3
P
3 = BP6
BP7
Assign cloud resource
P
4
P
4 = BP7 ∪ BP8
BP8
Repossess cloud resourceTable 3
Scopes and relations.
Scope number
Scope
Scope relations
S
1
Cloud resource lease affairs for all the enterprises
S
1
⊃
(
2
∪
S
3
)
S
2
Cloud resource lease affairs for manufacture enterprises
S
3
Cloud resource lease affairs for service enterprises
S
3
=
S
4
∪
S
5
S
4
Cloud resource lease affairs for hotel enterprises
S
5
Cloud resource lease affairs for restaurant enterprises
S
6
Hotel affairs
S
6
⊃
(
7
∪
S
10
)
S
7
Hotel room affairs
S
7
=
S
8
∪
S
9
S
8
Hotel room reception affairs
S
9
Hotel room service affairs
S
10
Hotel finance affairs
S
10
=
S
11
∪
S
12
S
11
Hotel accounting affairs
S
12
Hotel cashier affairs
S
13
Restaurant affairs
S
13
⊃
(
14
∪
S
17
)
S
14
Food and beverage affairs
S
14
=
S
15
∪
S
16
S
15
Food affairs
S
16
Beverage affairs
S
17
Restaurant finance affairs
S
17
=
S
18
∪
S
19
S
18
Restaurant accounting affairs
S
19
Restaurant cashier affairsBesides the permissions and scopes, in our 4D-role concept, user category and valid time are needed to be considered. Platform and tenant are two categories in the prototype. To make system simpler, every valid time ranges from −∞ to ∞.


### 4.2.2. Evaluation Results

After configuring permissions, scopes, valid time, and user categories as mentioned in Section4.2, we run the hotel and restaurant business in the prototype implemented in Section 4.1. We examine fields of user duties and find the boundaries of the fields. The users include the ones from both platform and tenants. Figure 10 shows the fields of user duties.Figure 10
Fields of user duties.In the figure, there are four platform users,U
4, U
5, U
7, and U
8. The user type of U
4, U
5, and U
7 is Platform Senior Admin, while the user type of U
8 is Platform Admin. On the other side, U
10, U
14, U
15, U
17, U
21, and U
22 are from two tenants. We can find from the figure that the fields of platform user are absolutely different from those of users from the two tenants. It indicates that the platform users have no rights to operate any data items in the tenants. The duties of platform users to the tenants are only operating the cloud resources such as assigning resources and repossessing resources. Moreover, the figure illustrates that the platform has an independent administration environment. It means that the administration never depends on applications or enterprises of tenant.Next, we verify the character of user hierarchy using the prototype. Figure11 shows the hierarchy structures of the users, no matter what user types they belong to.Figure 11
Hierarchy structure of the users. (a) Three users from the cloud platform. (b) Three users from the hotel tenant. (c) Three users from the restaurant tenant.
(a)
(b)
(c)In Figure11(a), the fields of the three users, U
4, U
5, and U
7, have a relation U
4
⊃
U
5
⊃
U
7. It means that the three users build a hierarchy structure. It is attributed to the fact that the corresponding scopes of the three users have relation that S
1
⊃
S
4
⊃
S
5, while the permissions of three users are the same. In Figure 11(b), there is a relation, U
9
⊃
U
13
⊃
U
14, existing in the fields of the three users U
9, U
13, and U
14. The reasons of becoming such hierarchy structure are from two aspects. On one hand, the permissions of the three users are P
1
∪
P
2
∪
P
3, P
1
∪
P
2, and P
1, respectively, which is an inclusive relation. On the other hand, scopes of the three users have inclusive relations that S
6
⊃
S
10
⊃
S
11. The same as U
9, U
13, and U
14 in Figure 11(b), in Figure 11(c), the users U
21, U
20, and U
16 become a hierarchy structure.Lastly, we compare the fields of the two tenants. Figure12 shows the fields of the hotel tenant and the restaurant tenant.Figure 12
Fields of the two tenants.Figure12 illustrates that there is no intersection between the fields of users U
9 and U
16. From the hierarchy structures shown in Figure 11, we can know that U
9 and U
16 have the largest fields in their own tenants. It infers that the two tenants are totally isolated. So, the character of tenant isolation is verified.


## 4.2.1. Business Functions

(a) User Functions.Functions of each user in the prototype are listed in Table 1. Depending on the defined users and functions, a user graph describing the structural relations among the users is shown in Figure 9.Table 1
Users and functions.
Number
User
User type
Functions
U
1
General Admin
General Admin
Set applications and user categories
U
2
Application Developer
Developer
Set basic permissions of applications
U
3
Platform Developer
Developer
Set basic permissions of the platform
U
4
Cloud platform manager
Platform Senior Admin
Manage cloud resource lease affairs for all the enterprises
U
5
Manager of admin  for  manufacture enterprises
Platform Senior Admin
Manage cloud resource lease affairs for manufacture enterprises
U
6
Manager of admin  for service enterprises
Platform Senior Admin
Manage cloud resource lease affairs for service enterprises
U
7
Admin of hotel enterprises
Platform Admin
Manage cloud resource lease affairs for hotel enterprises
U
8
Admin of restaurant enterprises
Platform Admin
Manage cloud resource lease affairs for restaurant enterprises
U
9
General Manger (hotel)
Application Administrator
Manage all the affairs in the hotel and approve management report
U
10
Manager of room division
Application Administrator
Manage room affairs and submit room management report
U
11
Room receptionist
Application User
Manage room reception affairs
U
12
Room attendant
Application User
Manage room service affairs
U
13
Manager of finance (hotel)
Application Administrator
Manage finance affairs and submit finance management report
U
14
Accountant (hotel)
Application User
Manage hotel accounting affairs
U
15
Cashier (hotel)
Application User
Manage hotel cashier affairs
U
16
General Manager (restaurant)
Application Administrator
Manage all the affairs in the restaurant and approve management report
U
17
Manager of Food and Beverage
Application Administrator
Manage food and beverage affairs and submit food and beverage management report
U
18
Food attendant
Application User
Manage food affairs
U
19
Beverage attendant
Application User
Manage beverage affairs
U
20
Manager of Finance (restaurant)
Application Administrator
Manage finance affairs and submit finance report
U
21
Accountant (restaurant)
Application User
Manage accounting affairs
U
22
Cashier (restaurant)
Application User
Manage cashier affairsFigure 9
A user graph describing the structural relations among the users.(b) Configuration of 4D-Role Based User.As the 4D-role in the 4D-RBMT model is composed of permission, scope, valid time, and user category, we configure the four elements of 4D-Role starting with the configuration of basic permission, while permission is a union of one or more basic permissions.We consider three types of basic permissions (BP) in the prototype. The first type is the management of information, including create, delete, update, and view on the conventional data items. The second type is related to the affairs about management report, which is composed of basic permission of submit and approve management reports. The third type which consists of assigning cloud resource and repossessing cloud resource is something about the management of cloud resource. Table2 shows the basic permissions and permissions in our prototype. Scopes are also configured and listed in Table 3. Relations existing among those scopes are also listed.Table 2
Basic permissions and permissions.
Basic permission number
Basic permission
Permission number
Permission
BP1
Create information
P
1
P
1 = BP1 ∪ BP2 ∪ BP3 ∪ BP4
BP2
Delete information
BP3
Update information
BP4
View information
BP5
Submit management report
P
2
P
2 = BP5
BP6
Approve management report
P
3
P
3 = BP6
BP7
Assign cloud resource
P
4
P
4 = BP7 ∪ BP8
BP8
Repossess cloud resourceTable 3
Scopes and relations.
Scope number
Scope
Scope relations
S
1
Cloud resource lease affairs for all the enterprises
S
1
⊃
(
2
∪
S
3
)
S
2
Cloud resource lease affairs for manufacture enterprises
S
3
Cloud resource lease affairs for service enterprises
S
3
=
S
4
∪
S
5
S
4
Cloud resource lease affairs for hotel enterprises
S
5
Cloud resource lease affairs for restaurant enterprises
S
6
Hotel affairs
S
6
⊃
(
7
∪
S
10
)
S
7
Hotel room affairs
S
7
=
S
8
∪
S
9
S
8
Hotel room reception affairs
S
9
Hotel room service affairs
S
10
Hotel finance affairs
S
10
=
S
11
∪
S
12
S
11
Hotel accounting affairs
S
12
Hotel cashier affairs
S
13
Restaurant affairs
S
13
⊃
(
14
∪
S
17
)
S
14
Food and beverage affairs
S
14
=
S
15
∪
S
16
S
15
Food affairs
S
16
Beverage affairs
S
17
Restaurant finance affairs
S
17
=
S
18
∪
S
19
S
18
Restaurant accounting affairs
S
19
Restaurant cashier affairsBesides the permissions and scopes, in our 4D-role concept, user category and valid time are needed to be considered. Platform and tenant are two categories in the prototype. To make system simpler, every valid time ranges from −∞ to ∞.


## 4.2.2. Evaluation Results

After configuring permissions, scopes, valid time, and user categories as mentioned in Section4.2, we run the hotel and restaurant business in the prototype implemented in Section 4.1. We examine fields of user duties and find the boundaries of the fields. The users include the ones from both platform and tenants. Figure 10 shows the fields of user duties.Figure 10
Fields of user duties.In the figure, there are four platform users,U
4, U
5, U
7, and U
8. The user type of U
4, U
5, and U
7 is Platform Senior Admin, while the user type of U
8 is Platform Admin. On the other side, U
10, U
14, U
15, U
17, U
21, and U
22 are from two tenants. We can find from the figure that the fields of platform user are absolutely different from those of users from the two tenants. It indicates that the platform users have no rights to operate any data items in the tenants. The duties of platform users to the tenants are only operating the cloud resources such as assigning resources and repossessing resources. Moreover, the figure illustrates that the platform has an independent administration environment. It means that the administration never depends on applications or enterprises of tenant.Next, we verify the character of user hierarchy using the prototype. Figure11 shows the hierarchy structures of the users, no matter what user types they belong to.Figure 11
Hierarchy structure of the users. (a) Three users from the cloud platform. (b) Three users from the hotel tenant. (c) Three users from the restaurant tenant.
(a)
(b)
(c)In Figure11(a), the fields of the three users, U
4, U
5, and U
7, have a relation U
4
⊃
U
5
⊃
U
7. It means that the three users build a hierarchy structure. It is attributed to the fact that the corresponding scopes of the three users have relation that S
1
⊃
S
4
⊃
S
5, while the permissions of three users are the same. In Figure 11(b), there is a relation, U
9
⊃
U
13
⊃
U
14, existing in the fields of the three users U
9, U
13, and U
14. The reasons of becoming such hierarchy structure are from two aspects. On one hand, the permissions of the three users are P
1
∪
P
2
∪
P
3, P
1
∪
P
2, and P
1, respectively, which is an inclusive relation. On the other hand, scopes of the three users have inclusive relations that S
6
⊃
S
10
⊃
S
11. The same as U
9, U
13, and U
14 in Figure 11(b), in Figure 11(c), the users U
21, U
20, and U
16 become a hierarchy structure.Lastly, we compare the fields of the two tenants. Figure12 shows the fields of the hotel tenant and the restaurant tenant.Figure 12
Fields of the two tenants.Figure12 illustrates that there is no intersection between the fields of users U
9 and U
16. From the hierarchy structures shown in Figure 11, we can know that U
9 and U
16 have the largest fields in their own tenants. It infers that the two tenants are totally isolated. So, the character of tenant isolation is verified.


## 4.3. Simulation Evaluation of Performance in Using Cloud Resources

It is significant to evaluate the performance of the prototype system in using cloud resources, especially in the cases when a lot of users are using the cloud platform simultaneously. Simulations that simulate behaviors of large-scale users are used to evaluate the performance.


### 4.3.1. Simulation Parameters

We use simulations to evaluate the performance of our proposed prototype in using cloud resources. In the simulations, performance of tenant systems and cloud platform is evaluated under different loads. The parameters of the simulations that simulate different scenarios include number of users, max number of concurrent users, and runtime. Table4 shows the details of parameters in the simulations.Table 4
Simulation parameters.
Parameter
Value
Description
Number of users
2500, 5000, 7500, 10000, 12500, 15000, 17500, 20000
The number of users in simulation
Max number of concurrent users
400–1000
The max number of concurrent users in simulation
Runtime
30 s–60 s
The runtime of simulationIn the evaluation, CPU usage and active memory are used to measure the running status of the tenant system and cloud platform. Besides CPU usage and active memory, response time is used to evaluate the system efficiency of our proposed system. There are three kinds of response time that are used to measure the performance. First one is average response time. It reflects the average experience of users. Next, max response time describes the worst case in using this prototype system. Last, line of 99% response time is the value of top 99% shortest response time in simulation, which gives the upper bound of most cases in using this prototype system.


### 4.3.2. Evaluation Results

Three rounds of simulations are run under light, normal, and heavy loads. After that, we analyze the data collected from vSphere monitor and evaluate the performance. Figure13 shows the CPU usage and active memory of one of the tenant systems and the cloud platform.Figure 13
CPU usage and active memory in the simulation. (a) CPU usage of cloud platform. (b) Active memory of cloud platform. (c) CPU usage of tenant system. (d) Active memory of tenant system.
(a)
(b)
(c)
(d)Figure13 illustrates that the max value of CPU usage and active memory, in both tenant and cloud platform, is growing with the increase of user number. The usage of CPU in the environment of light load reaches the peak of 22.08% for a tenant and 34.97% for the whole cloud platform. In the scenario of running under the normal load, the maximum of the CPU usage for the tenant and cloud platform is 25.05% and 43.43%, respectively. In the heavy load situation, the usage of CPU increases up to 37.9% for tenant and 48.92% for the cloud platform. Under the heavy load, the value for tenant increases to 51.3% compared with the environment under the normal load and 71.6% compared with that under the light load. Meanwhile, the increase ratios of CPU usage for cloud platform under the heavy load are 12.6% and 39.9%, compared to the situations under the normal and light loads. This indicates that the CPU usage for a cloud platform increases slower than that for a tenant. As for active memory, it has almost the same trend as the CPU usage.In addition, we evaluate the response time that indicates how long an authorization query is answered. Figure14 shows the response time in the simulation.Figure 14
Response time in the simulation. (a) Average response time. (b) Line of 99% response time. (c) Max response time.
(a)
(b)
(c)The number of users in simulations ranges from 2500 to 20000. According to Figure14, the average response time is increasing almost linearly and the line of 99% response time is also increasing smoothly. It indicates that the proposed system can keep a low latency performance in most of the scenarios. As for the max response time, the proposed system has an acceptable performance in these kinds of extreme situations, which appear at a quite low probability.The evaluation results above imply that our proposed system performed well in situations where large-scale users are operating in the cloud platform. Our proposed system can deal with the surge of user number with limited cloud resource. Meanwhile, it is able to provide high quality and low response service for most of the users.The experimental evaluation in Section4.2 shows that the 4D-RBMT model is business-oriented model for multitenant users in cloud platform. It is suitable not only for different enterprises as tenants to configure and manage users’ roles in cloud, but also for administrators of cloud providers to assign resources to the tenants and manage tenants’ role in the cloud. According to the evaluation in Section 4.3, the proposed system performed well in the situations of large amount of users who are operating in the cloud simultaneously.


## 4.3.1. Simulation Parameters

We use simulations to evaluate the performance of our proposed prototype in using cloud resources. In the simulations, performance of tenant systems and cloud platform is evaluated under different loads. The parameters of the simulations that simulate different scenarios include number of users, max number of concurrent users, and runtime. Table4 shows the details of parameters in the simulations.Table 4
Simulation parameters.
Parameter
Value
Description
Number of users
2500, 5000, 7500, 10000, 12500, 15000, 17500, 20000
The number of users in simulation
Max number of concurrent users
400–1000
The max number of concurrent users in simulation
Runtime
30 s–60 s
The runtime of simulationIn the evaluation, CPU usage and active memory are used to measure the running status of the tenant system and cloud platform. Besides CPU usage and active memory, response time is used to evaluate the system efficiency of our proposed system. There are three kinds of response time that are used to measure the performance. First one is average response time. It reflects the average experience of users. Next, max response time describes the worst case in using this prototype system. Last, line of 99% response time is the value of top 99% shortest response time in simulation, which gives the upper bound of most cases in using this prototype system.


## 4.3.2. Evaluation Results

Three rounds of simulations are run under light, normal, and heavy loads. After that, we analyze the data collected from vSphere monitor and evaluate the performance. Figure13 shows the CPU usage and active memory of one of the tenant systems and the cloud platform.Figure 13
CPU usage and active memory in the simulation. (a) CPU usage of cloud platform. (b) Active memory of cloud platform. (c) CPU usage of tenant system. (d) Active memory of tenant system.
(a)
(b)
(c)
(d)Figure13 illustrates that the max value of CPU usage and active memory, in both tenant and cloud platform, is growing with the increase of user number. The usage of CPU in the environment of light load reaches the peak of 22.08% for a tenant and 34.97% for the whole cloud platform. In the scenario of running under the normal load, the maximum of the CPU usage for the tenant and cloud platform is 25.05% and 43.43%, respectively. In the heavy load situation, the usage of CPU increases up to 37.9% for tenant and 48.92% for the cloud platform. Under the heavy load, the value for tenant increases to 51.3% compared with the environment under the normal load and 71.6% compared with that under the light load. Meanwhile, the increase ratios of CPU usage for cloud platform under the heavy load are 12.6% and 39.9%, compared to the situations under the normal and light loads. This indicates that the CPU usage for a cloud platform increases slower than that for a tenant. As for active memory, it has almost the same trend as the CPU usage.In addition, we evaluate the response time that indicates how long an authorization query is answered. Figure14 shows the response time in the simulation.Figure 14
Response time in the simulation. (a) Average response time. (b) Line of 99% response time. (c) Max response time.
(a)
(b)
(c)The number of users in simulations ranges from 2500 to 20000. According to Figure14, the average response time is increasing almost linearly and the line of 99% response time is also increasing smoothly. It indicates that the proposed system can keep a low latency performance in most of the scenarios. As for the max response time, the proposed system has an acceptable performance in these kinds of extreme situations, which appear at a quite low probability.The evaluation results above imply that our proposed system performed well in situations where large-scale users are operating in the cloud platform. Our proposed system can deal with the surge of user number with limited cloud resource. Meanwhile, it is able to provide high quality and low response service for most of the users.The experimental evaluation in Section4.2 shows that the 4D-RBMT model is business-oriented model for multitenant users in cloud platform. It is suitable not only for different enterprises as tenants to configure and manage users’ roles in cloud, but also for administrators of cloud providers to assign resources to the tenants and manage tenants’ role in the cloud. According to the evaluation in Section 4.3, the proposed system performed well in the situations of large amount of users who are operating in the cloud simultaneously.


## 5. Conclusion

The paper presented a 4D-role, which is a set of four-dimensional vectors, forming asp
e
r
m
i
s
s
i
o
n
,
s
c
o
p
e
,
v
a
l
i
d
t
i
m
e
,
u
s
e
r
c
a
t
e
g
o
r
y. According to the four-dimensional role, we proposed a 4D-role based multitenancy (4D-RBMT) model using a level based structure. The 4D-RBMT model is able to make users work in their own scopes during their valid time by assigning different permissions, scopes, valid time, and user category to each role. It is proved in mathematic approaches that the 4D-RBMT model has characters of tenant isolation, role hierarchy, and administration independence. Such three characters of the model are also verified by experimental evaluation. In addition, the evaluation results indicate that the 4D-RBMT based prototype system performs well in using cloud resources, especially in the scenarios where large-scale users are operating in the cloud platform simultaneously. The 4D-RBMT model can be used effectively in developing a tenant management system for multitenancy cloud platforms.



---

*Source: 2935638-2016-02-28.xml*