Literature

J Supercomput (2013) 66:1111–1131 DOI 10.1007/s11227-013-1017-5

Contract RBAC in cloud computing

Hsing-Chung (Jack) Chen · Marsha Anjanette Violetta · Cheng-Ying Yang

Published online: 1 October 2013 © Springer Science+Business Media New York 2013

Abstract Cloud computing is a fast growing field, which is arguably a new com- puting paradigm. In cloud computing, computing resources are provided as services over the Internet and users can access resources based on their payments. The issue of access control is an important security scheme in the cloud computing. In this paper, a Contract RBAC model with continuous services for user to access various source services provided by different providers is proposed. The Contract RBAC model ex- tending from the well-known RBAC model in cloud computing is shown. The ex- tending definitions in the model could increase the ability to meet new challenges. The Contract RBAC model can provide continuous services with more flexible man- agement in security to meet the application requirements including Intra-cross cloud service and Inter-cross cloud service. Finally, the performance analyses between the traditional manner and the scheme are given. Therefore, the proposed Contract RBAC model can achieve more efficient management for cloud computing environments.

Keywords RBAC · Datacenter · Cloud computing · Contract · Contract RBAC

H.-C. Chen (B) · M.A. Violetta Department of Computer Science and Information Engineering, Asia University, Taichung 41354, Taiwan e-mail: [email protected]

H.-C. Chen e-mail: [email protected]

M.A. Violetta e-mail: [email protected]

C.-Y. Yang (B) Department of Computer Science, Taipei Municipal University of Education, Taipei 10048, Taiwan e-mail: [email protected]

1112 H.-C. Chen et al.

1 Introduction

Cloud computing is a colloquial expression used to describe a variety of different types of computing concepts that involve a large number of computers connected through a real-time communication network such as the Internet [13]. Cloud comput- ing based on services computing and resource virtualization technologies has become popular recently. There are massively scalable computing capabilities provided as ser- vices to multiple customers simultaneously [14]. However, there still exist problems related to security. People dare not use this kind service. For reasonable concerns, the consideration of the cloud computing should include security and users’ privacy. Specially, it is an important issue on the outsourced data [11]. It needs an effective management for security.

Datacenter (DC) is the storage for the outsourced data and defined as one massive scale computer. It is responsible for handling the tasks from the end user. Hence, it provides data services to the users with different devices and allows the authenticated user to access the cloud and to use the applications inside [2]. For the purpose of management, an access control scheme is needed for using these authenticated appli- cations. Role-Based Access Control (RBAC) is one of the access control models to accommodate organizational access policies [3].

RBAC, introduced by Ferraiolo and Kuhn, has become the predominant model for the advanced access control because it reduces the complexity and cost of secu- rity administration in large networked applications [4, 5, 10]. With RBAC, system administrators create roles according to the job functions performed in an organiza- tion, grant permissions to those roles, and then assign users to the roles on the basis of their specific job responsibilities and qualifications [5, 8, 10]. In the cloud com- puting system, there are a great number of users who hope to make the access to the cloud computing services. They do have their own goals and behaviors. If the cloud computing system hopes to deal with them one by one, there will be a lot of hard work [12]. However, the conventional RBAC model [4, 8, 10] does not address the implementation in cloud computing. Access control is an important management scheme in cloud computing. Access control should be different between the one used Cloud Computing Environment (CCE) and the one used in the traditional access en- vironment. In this paper, a Contract RBAC model applied to cloud computing is pro- posed. The proposed Contract RBAC model in cloud computing is the extension from the well-known RBAC model. The required definitions and functions for the model are proposed in this paper. They can increase the ability of the conventional RBAC model to meet the new challenges. In the proposed model, DC provides and manages the permissions of services. For more efficiently managing permissions of services, users can register to the Cloud Service Provider (CSP) to get contract roles, permis- sions, and access corresponding services under the contract made by CSPs. In the meantime, the users could get either more services or a high QoS.

The rest of this paper is organized as follows: The related works of cloud com- puting and RBAC are addressed in Sect. 2. In Sect. 3, a generalized Contract RBAC in cloud computing is proposed. The definitions and functions for this model are de- scribed. In Sect. 4, there are three application scenarios. Performance analyses are described in Sect. 5. Finally, conclusions are given in Sect. 6.

Contract RBAC in cloud computing 1113

2 Related works

2.1 Cloud computing

Cloud computing is a fast growing field, which is arguably a new computing paradigm. In cloud computing, computing resources are rendered as services over the Internet. Various definitions on cloud computing can be seen from the academia, the government, and the industry. According to the US National Institute of Sci- ence and Technology (NIST), “Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.” In a more precise definition, cloud computing is defined as “both the ap- plications delivered as services over the Internet and the hardware and systems soft- ware in the DC that provide those services.” As a low-cost solution, cloud computing provides computation, software, data access, and storage services that are transparent to end users [9].

The basic principles of cloud computing are summarized as follows: Cloud com- puting describes a new delivery model for IT services based on the Internet, and it typically involves over-the-Internet provision of dynamically scalable and often vir- tualized resources. It is a by-product and consequence of the ease-of-access to remote computing sites provided by the Internet. This frequently takes the form of web-based tools or applications that users can access and use through a web browser as if it is a program installed locally on their own computer [1].

Depending on the nature of customers, a cloud can be deployed as a private cloud, community cloud, public cloud, and hybrid cloud. Cloud computing is essentially a centralized (from the users’ perspective) computing facility built on a large-scale ser- vice model. It has been argued, especially by the academia that cloud computing is nothing new than its predecessors such as autonomic computing, client-server model, grid/cluster computing, mainframe computers, utility computing, service-oriented computing, Web 2.0, platform virtualization, Service Oriented Architecture (SOA), and peer-to-peer networks, although the resources can be provided on a much larger scale compared to previous applications [9].

However, cloud computing offers scalable on-demand services to consumers with a greater flexibility and a lesser infrastructure investment [7]. Since cloud services are delivered by using classical network protocols over the Internet, cloud computing implicates vulnerabilities existing in these protocols as well as threats introduced by newer architectures. Also, it raises many security and privacy concerns [7].

2.2 Role based access control

RBAC is known to be good method of control for allowing users to access resources. The main function of RBAC is to prevent an unauthorized user from gaining infor- mation to which they are not entitled. Access rights are grouped by role name, and the use of resources is restricted to individuals authorized to assume the associated role. The use of roles to control access can be an effective means for developing

1114 H.-C. Chen et al.

and enforcing enterprise-specific security policies, and for streamlining the security management process.

RBAC [8, 10] is defined in terms of four model components: Core RBAC, Hi- erarchical RBAC, Static Separation of Duty Relations, and Dynamic Separation of Duty Relations. This includes user-role assignment and permission-role assignment relations. Core RBAC includes sets of five basic data elements such as Users (U ), Roles (R), Objects (OBJ), Operations (OPT ), and Permissions (PRMS). Users are considered as human being, machines, networks, or intelligent agents that can per- form some activities. Roles are described as a set of permissions necessary to access the resources. Permissions are approvals to execute operations on one or more ob- jects. Operations are executions of a program specific function that is invocated by a user. Objects are entities that contain or receive information, or have exhaustible system resources. Furthermore, Core RBAC introduces the concept of role activation as part of a user’s session within a computer system [4, 8, 10].

2.3 Cognitive RBAC in small heterogeneous networks

First, the Generalized Cognitive RBAC in Small Heterogeneous Networks (SHNs) is proposed by H.-C. Chen and Marsha A.V. [4]. The model is proposed with the char- acteristics of cognitive RBAC. It is able to integrate various types of access networks in SHNs. The intelligent capabilities [6] in SHNs are located in the Cognitive Server (CS) [20]. In SHNs, assigned networks and available channels are integrated as ac- cess resources. There are three phases for a user using her/his device(s) to register and access a CS [4]: Phase I is the user registration; see Fig. 1.

Phase II is the device registration; see Fig. 2. Phase III is the access phase; see Fig. 3. The basic concept of a Cognitive RBAC model [4] consists of the following sets:

Users (U ), Roles (R), Permissions (PRMS), Sessions (S), Devices (Dυ), Channels (CH), and Networks (N ε), representing the set of users, roles, permissions, sessions, devices, channels, and networks set. Users, denoted as a set U , are considered as

Fig. 1 User registration phase [4]

Contract RBAC in cloud computing 1115

Fig. 2 Device registration phase [4]

Fig. 3 Access phase [4]

authenticated users who can establish (wireless) communication with the resources of the CS to perform some activities. Roles, described as a set R, are assigned with permissions to access the resources of the CS. Permissions, PRMS, are a set of ap- provals to execute operations on one or more objects of the DC. Sessions, a set S, are the mappings between networks N ε and an activated subset of the set of roles R. Devices are a set Dυ considered as the mobile units used by assigned users to activate the roles and access permissions. Channels are a set CH considered as conveyers of the information signals from senders to receivers for the operation. Networks are a set

1116 H.-C. Chen et al.

N ε considered as computers interconnected by communication channels that allow sharing of resources and information [6].

It is assumed that the CS can identify the device whether it is registered or not, and determine who the device owner is. The CS also assigns and manages all of the access networks and available channels for each role, and dynamically adapts the access networks and available radio channels, depending on their environment, as needed for application performance. The generalized model of Cognitive RBAC is described in Definition 1 [4].

Definition 1 The generalized model of Cognitive RBAC;

• Users (U ), Roles (R), Permissions (PRMS), Sessions (S), Devices (Dυ), Chan- nels (CH), and Networks (N ε), representing the set of users, roles, permissions, sessions, devices, channels, and networks set which are assigned by the CS, re- spectively;

• UA ⊆ U × Dυ × R is the user assignment relation that associates users with their devices will be assigned the available roles after successful user and device authen- tication;

• r_au(r ∈ R) → 2U ×Dυ is the mapping of a role r onto a set U × Dυ of power set of authenticated users with their devices, where function r_au(•) is defined as r_au(r ∈ R) = {(u, dυ) ∈ U × Dυ|(u, dυ, r) ∈ UA};

• ηε is a network ηε ∈ N εψ ′ , where N εψ ′ , a set of networks, and ψ is a system of networks;

• CHηε is a set of channels and corresponding to a network ηε ∈ N εψ ′ ; • ch ∈ CHηε is an available channel in a channel set CHηε which belongs to a net-

work ηε ∈ N εψ ′ ; • CHAηε ⊆ CHηε ×Dυ is the channel assignment relation that the available channels

CHηε assigned to a smart device dυ ⊆ Dυ via a network ηε which is managed by a CS;

• PA ⊆ R × N εψ × CHηε × PRMS is the role assignment relation that assigns per- mission to an available role, network and channel;

• r_p(r ∈ R, ηε ∈ N εψ , ch ∈ CHηε) → 2PRMS is the mapping of a role r , a network ηε and a channel ch onto a set PRMS of power set of permissions, where the function r_p(•) is defined as r_p(r, ηε, ch) = {p ∈ PRMS|(r, ηε, ch, p) ∈ PA};

• u_s((u, dυ) ∈ U × Dυ) → 2S is the mapping of a user with his device (u, dυ) onto a set S of power set of sessions;

• s_r(ς ∈ S) → 2R is the mapping of a session ς onto a set R of power set of roles; • avail_s_p(ς ∈ S, ηε ∈ N εψ , ch ∈ CHηε) → 2PRMS is the mapping of a network

ηε and a channel ch in a session ς onto a set PRMS of power set of available permissions; the permissions assign to the user as below:

⋃ r∈s_r(ς) r_p(r, ηε, ch).

Hierarchies in the Cognitive RBAC model are defined as an inheritance relation- ship between two roles managed by the CS, such that a role ri ∈ R inherits the per- missions from role, rj ∈ R, if all permissions of rj are also the permissions of ri . The hierarchical Cognitive RBAC model for the CS is presented in Definition 2 [4]. In this model, permissions are assigned to a role.

Contract RBAC in cloud computing 1117

Definition 2 Role hierarchies in a Cognitive RBAC model;

• RH ⊆ R × R × N εψ × CHηε is a hierarchy relation with a partial order of roles, called the role ascendancy relation combined with networks and channels. For ex- ample, ri � rj is such that the role ri ∈ R inherits all permissions which are as- signed to all the users of rj , where the ascendancy relation is denoted as “ �”;

• r_p(ri ∈ R, ηεm ∈ N εψ , chc ∈ CHηε) → 2PRMS is the mapping of a role ri , a network ηεm, and a channel chc onto a set PRMS of power set of permis- sions. The permissions are assigned directly together with all the permissions assigned to their successive roles who could use the permissions including not only the power set of combined network ηεm and channel chc , but also the power set of combined network ηεn and channel che. Specifically: r_p(ri , ηεm, chc) = r_p(ri ) ∪ {

⋃ ∀rj :ri �rj r_p(rj , ηεn, che)};

• r_au(ri ∈ R) → 2U ×Dυ is the mapping of a role ri onto a set U × Dυ of power set of authenticated users with their devices in the presence of a role hierarchy, specifically: r_au(ri ) = {(u, dυ) ∈ U × Dυ|ri � rj , (u, dυ, ri ) ∈ UA};

• r_n(ri ∈ R) → 2Nεψ ×Ch is the mapping of a role ri onto a set Nεψ × Ch of power set of networks together with channels. The set of networks together with related channels assigned directly to its successive roles. Specifically:

From the above sub-definitions, it follows that if r_p(rj , ηεn, che) ⊆ r_p(ri , ηεm, chc) and r_au(rj ) ⊆ r_au(ri ).

Separations of Duties are defined in Definition 3 [4] and Definition 4 [4] as those are to be enforced on a set of roles that may not be executed simultaneously by a user. Their model would be similar to the well-known RBAC model.

(1) Static Separation of Duty (SSD) relations place constraints on the assignments of users to roles. Membership of one role may prevent the user from being a member of one or more other roles, depending on the SSD enforced rules.

Definition 3 SSD relation in the Cognitive RBAC model;

• SSD, SSD ∈ 2R × 2N εψ × 2CHηε × N is a collected relation set (α, β, χ, ) repre- sented as (2R, 2N εψ , 2CHηε , N ) for CS, where α is a subset belonging to the power set of roles 2R , β is a subset belonging to the power set of networks 2N εψ , χ is a subset belonging to the power set of channels 2CHηε , and ∈ N is a natural num- ber, ≥ 2 with the property that no user can be assigned to or more roles from the role subset α in any network subset β or channel subset χ . Specifically:

∀(α, β, χ, ) ∈ SSD, ∀η ∈ α : |η| ≥ ⇒ ⋂

∀r∈η r_au(r) = ∅.

(2) Dynamic Separation of Duty (DSD) relations differ from SSD relations by the context in which these limitations are imposed. DSD requirements limit the avail- ability of the permissions by placing constraints on the roles that can be activated within or across a user’s sessions.

Definition 4 DSD relation in the Cognitive RBAC model;

1118 H.-C. Chen et al.

• DSD, DSD ⊆ 2R × 2N εψ × 2CHηε × N is a collected relation set (α, β, χ, ν) rep- resented as (2R, 2N εψ , 2CHηε , N ) for CS, where α ∈ 2R is a role subset, β ∈ 2N εψ is a network subset, χ ∈ 2CHηε is a channel subset, and ν ∈ N is a natural number, ν ≥ 2 with the property that no user may activate ν or more roles from the role subset α in any network subset β or channel subset χ . Specifically:

∀(α, β, χ, ν) ∈ DSD, ∀ς ∈ S, ∀ρ ⊆ {α ∩ s_r(ς)} : |ρ| ≥ ν ⇒ ⋂

r∈ρ r_au(r) = ∅,

where ς ∈ S is a session belonging to the user’s session set S.

3 Contract RBAC model in cloud computing

In order to deal with RBAC on CCE, a novel generalized Contract RBAC model is proposed to meet the new management requirements in cloud computing. The Con- tract RBAC inherits the advantages from RBAC standard. It could provide a better QoS, security, and access control in CCEs. First, it assumes that DC provides and manages the permissions of services in the Contract RBAC model. For a more effi- cient managing to permissions of services, users are allowed to register to CSP to get contract roles and permissions to access corresponding services under the contract made by CSPs to get better QoS if users need more services. In this paper, a new role “contract role” is proposed, which can achieve to flexibly manage the role mapping in cloud computing. The contract role is depending on the contract made by CSPs. In the following, the basic definition for the generalized Contract RBAC model is given.

3.1 The basic definition of the contract RBAC model in cloud computing

The basic concept of the generalized Contract RBAC model consists of the following component sets: Users (U ), Contract Roles (CR), Permissions (PRMS), Roles of Dat- acenter (RDC ), Sessions (S), representing the set of users, contract roles, permissions, roles of datacenters, sessions set. Users are a set U considered as authenticated users who can establish communication with the resources of the DC to perform some ac- tivities. Permissions, PRMS, are a set of approvals to execute operations on one or more objects of the DC. Roles of Datacenter (RDC), RDC , are described as a set role of permissions to access the resources of the DC. Contract Roles are combined the mapping roles from Roles of Datacenter, representing as a contract role set CR depending on the contract made by each CSP, as shown in Fig. 4, individually.

Sessions, S, based on the contract role set CR, are a session set of the mappings between user set and an activated subset of the set of the contract role set CR. Each CSP assigns users to contract role. The DC manages the permissions which let users could access resources from its server. The generalized model of Contract RBAC in cloud computing is described in Definition 5.

Definition 5 The generalized model of Contract RBAC;

Contract RBAC in cloud computing 1119

Fig. 4 Contract RBAC in cloud computing

• UA ⊆ U (k) × CR(k)is the user assignment relation that associates users to contract roles CR(k) ⊆ R(k)DCd × R

(k′) DC

d̂ , where k and k′ are the notations to indicate the differ-

ent CPSs: CSP(k) is a serving CPS and CSP(k ′) is a target CPS, and d is the notation

to indicate deployment model of CCE, there are Public cloud (pu), Private cloud (pv) and Hybrid cloud (hy);

• r_au(k)(cr(k) ∈ CR(k)) → 2U (k) is the mapping of a contract role at a serving DCd in a CSP(k) onto a power set of authenticated users 2U

(k) , where the function

r_au(k)(•) is defined as r_au(k)(cr(k)) = {u(k) ∈ 2U (k) |(u(k), cr(k)) ∈ UA}; • PA ⊆ R(k)DCd × PRMS

(k) is the permission assignment relation that it assigns the

permissions to available Roles of Datacenter at a serving DCd in a CSP (k);

• r_p(k)(r(k)dcd ∈ R (k) DCd

) → 2PRMS(k) is the mapping of a role r(k)dcd of serving datacenter DCd in a CSP

(k) onto a subset prms(k) of power set of permissions 2PRMS (k)

, where R

(k) DCd

⊆ CR(k) and the function r_p(k)(•) is defined as: r_p(k)(r(k)dcd ) = {prms(k) ∈ 2PRMS

(k) |(r(k)dcd , prms(k)) ∈ PA}; • CRA ⊆ R(k)DCd × R

(k′) DC

d̂ is the contract role assignment relation that associates a role

of a serving datacenter DCd from a CSP (k) with a role of target datacenter DC

d̂

from a CSP(k ′) to contract role;

• rdc_cr(k)(r(k)dcd ∈ R (k) DCd

, r (k′) dc

d̂ ∈ R(k′)DC

d̂ ) → 2CR(k) is the mapping of a role of serving

datacenter DCd in a CSP (k) together with a role of target datacenter DC

d̂ in a

serving CSP(k ′) onto a set of contract roles, where function rdc_cr

(k)(•) is defined as rdc_cr

(k)(r (k) dcd

, r (k′) dc

d̂ ) = {cr(k) ∈ CR(k)|(cr(k), r(k)dcd , r

(k′) dc

d̂ ) ∈ CRA};

• u_s(k)(u(k) ∈ U (k)) → 2S(k) is the mapping of a user onto a power set of sessions at a serving DCd in a CSP

(k);

1120 H.-C. Chen et al.

• s_r(k)(ς (k) ∈ S(k)) → 2CR(k) is the mapping of a session ς (k) onto a power set of contract roles at a serving DCd in a CSP

(k); • avail_s_p(k)(ς (k) ∈ S(k), U (k)) → 2PRMS(k) is the mapping of available permis-

sions from a multiple session subset ς (k) constrained by the assigned by the as- signed contract role ∀cr(k) ∈ CR(k); and the user gets the her/his permissions as⋃

cr(k)∈s_r(k)(ς (k)) r_p (k)(cr(k) ∈ CR(k)) at a serving DCd in a CSP(k).

3.2 Hierarchical role in contract RBAC in cloud computing

Hierarchies in the Contract RBAC model are defined as an inheritance relationship within two roles of datacenter managed by the DC, such that a role of serving datacen- ter, rdcd ∈ RDCd , inherits the permissions from role of target datacenter, rdcd̂ ∈ RDCd̂ , if all permissions of rdcd are also the permissions of rdcd̂ . In Definition 6, the hierar- chical Contract RBAC model is presented for the DC. In this model, a contract role cr

(k) i

∈ CR(k) inherits the permission contract role cr(k) j

∈ CR(k). Definition 6 Role hierarchies in a Contract RBAC model;

• RH ⊆ CR(k) × CR(k′) is a partial order of contract role relation, called the ascen- dancy contract relation, written as ‘�’ for simple, where cr(k)

i � cr(k′)

j , is such that

a contract role cr(k) i

∈ CR(k) inherits all contract roles of datacenter cr(k′) j

∈ CR(k′); and all the users who are assigned the contract role cr(k)

i also can access the per-

missions of cr(k ′)

j ;

• r_p(cr(k) ∈ R(k)DCd ∪ R (k′) DC

d̂ ) → 2PRMS(k)∪PRMS(k

′) is the mapping of a contract role

onto a set of permissions which are assigned directly to the set R(k)DCd , and the

successive set R(k ′)

DC d̂ . Specifically,

r_p ( cr(k)

) = r_p(r(k)dcd ∈ cr (k)

) ∪ {

⋃

∀cr(k′):r(k′)dc d̂

≺r(k)dcd

r_p ( r (k′) dc

d̂

) }

;

• r_au(cr(k) ∈ CR(k)) → 2U (k)∪U (k ′)

is the mapping of a contract role cr(k) i

onto a set of authenticated users in the presence of a role of contract role hierarchy. Specifi- cally,

r_au ( cr

(k) i

) = {u(k) ∈ U (k)|cr(k) i

� cr(k′) j

, ( u

(k) , cr

(k) i

) ∈ UA(k)

and ( u

(k) , cr

(k′) j

) ∈ UA(k′)}; From the above sub-definitions, it follows that if r_p(r(k

′) dc

d̂ ) ⊆ r_p(r(k)dcd ) and

r_au(cr(k ′)

j ) ⊆ r_au(cr(k)

i ).

3.3 Separation of duties constrained in the contract RBAC in cloud computing

The proposed RBAC model defines Separation of Duties in Definition 7 and Def- inition 8, respectively, as those are to be enforced on a set of roles that cannot be

Contract RBAC in cloud computing 1121

executed simultaneously by a user. Their model would be similar to the well-known RBAC model.

(1) SSD relations place constraints on the assignments of users to contract roles. Membership of one role could prevent the user from being a member of one or more other contract roles, depending on the SSD constraints.

Definition 7 SSD relation in the Contract RBAC model in cloud computing

• SSD(k), SSD(k) ⊆ 2CR(k) × N (k) is a collection relation set (α, n) ⊆ (2CR(k) , N (k)) for CSP(k) and CSP(k

′) according to their contract, where α ⊆ 2CR(k) is a contract role subset and n ∈ N (k) is a natural number, n ≥ 2 with the property that no user can be assigned to n or more contract roles from the set α. Specifically, ∀(α, n) ∈ SSD(k), ∀η ∈ α : |η| ≥ n ⇒ ⋂∀cr(k)∈η r_au(k)(cr(k)) = ∅.

(2) DSD relations differ from SSD relations by the context in which these limitations are imposed. DSD requirements limit the availability of the permissions by plac- ing constraints on the contract roles that can be activated within or across a user’s sessions.

Definition 8 DSD relation in the Contract RBAC model in cloud computing.

• DSD(k), DSD(k) ⊆ 2CR(k) × N (k) is a collection of two (α, n) ∈ (2CR(k) , N (k)) for CSP(k) and CSP(k

′) according to their contract, where each α ⊆ 2CR(k) is a contract role set and ν ∈ N (k) is a natural number, ν ≥ 2 with the property that no user may activate ν or more contract roles from the set α. Specifically,

∀(α, ν) ∈ DSD(k), ∀ς (k) ∈ S, ∀ρ ⊆ {α ∩ s_r(ς)} : |ρ| ≥ ν ⇒

⋂

cr(k)∈ρ r_au(k)

( cr(k)

) = ∅,

where ς ∈ S is a session belonging to the user’s session set S.

3.4 Contract and registration phase and access phase

The works, in summary, for DC and the CSP could be divided into two phases: the first one is the Contract and Registration Phase, and the second one is the Access Phase. Sequentially, the two phases for the generalized Contract RBAC model applied in CCEs are introduced.

3.4.1 Contract and registration phase

A contract is an agreement having a lawful object entered into voluntarily by two or more parties, each of whom intends to create one or more legal obligations between them. Usually, it is made formally in writing. Registration has to make formally by submitting a document to, and received approval for a specific activity from, the appropriate official or authority. In this phase, the contract and registration which is suitable for this application scenario are described in the following.

1122 H.-C. Chen et al.

Table 1 An example to illustrate the mapping among CSP(A), DCs and permissions

Cloud Service Provider A CSP(A)

Datacenter DC (A) x Role of Datacenter R

(A) DCx

Permission of Service PRMS(A)

DC (A) pu1

r (A) dcpu1.1

prms (A) 1

r (A) dcpu1.2

prms (A) 2

r (A) dcpu1.3

prms (A) 3

r (A) dcpu1.4

prms (A) 4

r (A) dcpu1.5

prms (A) 5

DC (A) pu2

r (A) dcpu2.1

prms (A) 6

r (A) dcpu2.2

prms (A) 7

r (A) dcpu2.3

prms (A) 8

r (A) dcpu2.4

prms (A) 9

r (A) dcpu2.5

prms (A) 10

Table 2 An example to illustrate the mapping among CSP(B), DCs and permissions

Cloud Service Provider B CSP(B)

Datacenter DC (B) y Role of Datacenter R

(B) DCy

Permission of Service PRMS(B)

DC (B) pv1

r (B) dcpv1.1

prms (B) 1

r (B) dcpv1.2

prms (B) 2

r (B) dcpv1.3

prms (B) 3

r (B) dcpv1.4

prms (B) 4

r (B) dcpv1.5

prms (B) 5

DC (B) hy1

r (B) dchy1.1

prms (B) 6

r (B) dchy1.2

prms (B) 7

r (B) dchy1.3

prms (B) 8

r (B) dchy1.4

prms (B) 9

r (B) dchy1.5

prms (B) 10

(1) Contract phase In the assumption, CSP has the full power to manage all its own DCs. DC is the large RBAC server, which can manage the services for providing de- ployment model of CCEs: public cloud, private cloud, and hybrid cloud. CSP will make the contracts that provide privileges to access permissions of services in the DC. The contracts are made by two or more CSPs to satisfy inter-cross service. Sim- ilarly, the contracts could be made by DCs to satisfy intra-cross service. They map services from DC, assigned role of providers from the CSP in Table 1, Table 2, Ta- ble 3, and Table 4 for a registered user, and then they force SSD and DSD constraint with contract.

Contract RBAC in cloud computing 1123

Table 3 An example to illustrate the contract Inter-Cross Service

CR CSP

Cloud Service Provider A CSP(A)

Cloud Service Provider B CSP(B)

Contract Role Set CR(A⊆B)

Role of Datacenter in Provider A R

(A) DCx

Role of Datacenter in Provider B R

(B) DCy

cr (A⊆B) 1 r

(A) dcpu1.1

, r (A) dcpu2.2

r (B) dchy1.1

, r (B) dchy1.2

, r (B) dcpv1.1

cr (A⊆B) 2 r

(A) dcpu2.2

, r (A) dcpu2.3

r (B) dcpv1.1

, r (B) dcpv1.2

cr (A⊆B) 3 r

(A) dcpu1.4

, r (A) dcpu2.2

r (B) dcpv1.4

, r (B) dcpv1.2

cr (A⊆B) 4 r

(A) dcpu2.4

, r (A) dcpu2.4

r (B) dcpv1.4

, r (B) dcpv1.5

cr (A⊆B) 5 r

(A) dcpu2.5

r (B) dcpv1.5

Table 4 An example to illustrate the contract intra-cross service

Cloud Service Provider B CSP(B)

Contract Role Set CR(B) Datacenter DC (B) hy1

Datacenter DC (B) pv1

cr (B) 1 r

(B) dcpv1.1

r (B) dchy1.1

cr (B) 2 r

(B) dcpv1.2

r (B) dchy1.2

cr (B) 3 r

(B) dcpv1.3

r (B) dchy1.3

cr (B) 4 r

(B) dcpv1.4

r (B) dchy1.4

cr (B) 5 r

(B) dcpv1.5

r (B) dchy1.5

(2) Registration phase It assumes that a user initials a registration request to a CSP(k), and then the CSP(k) will make a User-to-CSP contract with the user. The CSP(k) will deliver assigned role(s) to its own DC. Then the DC will arrange the services to the mapping role according to the contract, and force SSD and DSD con- straints with contract.

Based on the mentioned above, the user has to finish registration to CSP(k) in an online system according to Algorithm 1. The user will get user ID, uID(k)u . Based on the registration, CSP(k) will assign a contract role cr(k)

j ∈ CR(k) to the user, where the

contract role will be mapped to DC. The DC consisting of roles set of datacenter with permissions of services. It shows an example to illustrate how users are mapped to the contract roles in order to satisfy the intra-cross service and inter-cross service in Table 5.

3.4.2 Access phase

After finishing the registration phase, the user could use the assigned contract role to activate some services from the serving DC managed by the CSP(k) according to her/his contract. According to Algorithm 2, the contract role will be authenticated by

1124 H.-C. Chen et al.

Algorithm 1 User(s) Registration Procedure in Cloud Service Provider(s)

Input: uID(k)u ; Output: cr(k) ∈ CR(k); 1: Begin 2: The user registers to CSP(k) in an online system; 3: If (CSP(k) receives uID(k)u ) then 4: If (uID(k)u /∈ U (k)) then 5: a. The CSP(k) notifies the user needs to do registration; 6: b. The Registration phase should be ended; 7: else 8: The CSP(k) will find out the signed contract; 9: End If; 10: While (uID(k)u ∈ U (k)) 11: Do {CSP(k) assigns the contract role, cr(k)

j ∈ CR(k), to the user,

where the 12: contract role with the role mapping to its related DC(x)};

End While; 13: Return;

Table 5 An example to illustrate how users are assigned to the contract roles

Users Contract Roles

Intra-Cross Service Inter-Cross Service

u (k) 1 cr

(B) 1 , cr

(B) 3 cr

(A⊆B) 1

u (k) 2 cr

(B) 5 , cr

(B) 2 cr

(A⊆B) 2 , cr

(A⊆B) 3

u (k) 3 cr

(B) 3 , cr

(B) 5 cr

(A⊆B) 2

u (k) 4 cr

(B) 4 cr

(A⊆B) 5 , cr

(A⊆B) 4

u (k) 5 cr

(B) 2 cr

(A⊆B) 4

CSP(k). If the role is illegal, CSP(k) will reject the request. Otherwise, if the role is legal, the user acts as the role which can activate one or multiple contract role(s) in order to access the services at DC. If the user wants to require more services from another DC in the same CSP(k), DC will give the requested services based on the contract. Due to the serving CSP(k) cannot provide the requested services by the user, the serving CSP(k) will initial a request to another CSP(k

′) according to the user’s contract and the CSP(k)-to-CSP(k

′)’s contract.

3.5 Continuous services

The Contract RBAC model can provide continuous services with more flexible man- agement in security where the services meet the customized domains: intra-cross cloud and inter-cross cloud. Thus, the continuous services consist of intra-cross ser- vice and inter-cross service. Each continuous service is maintained by updating con-

Contract RBAC in cloud computing 1125

Algorithm 2 User(s) Access Procedure in Cloud Service Provider(s)

Input: cr(k) ∈ CR(k); Output: Activate the cr(k) ∈ CR(k) to access the services from a DCx of a CSP(k); 1: Begin 2: The user accesses services from the DC(x) by using her/his contract

roles cr(k) ∈ CR(k);

3: If (the contract role authenticated by the CSP(k) is illegal) 4: Reject the access request; 5: Else 6: Activate the contract role cr(k) ∈ CR(k) to access the services

from the DC(x); 7: End If; 8: While (the user needs more services from intra-CSP(k)) 9: Do { 10: a. User will activate another contract role cr′(k) ∈ CR(k) from

another DC(y); 11: b. DC(y) will provide requested services}; 12: End While; 13: While (the user needs more services from inter-CSP(k

′)) 14: Do { 15: a. CSP(k) will help to request and get response from another CSP(k

′); 16: b. User will activate new contract role cr′′(k) ∈ CR(k) from another DC(z)

in CSP(k ′);

17: c. DC(z) at another CSP (k′) will provide the requested services from

the user }; 18: End While; 19: Return;

tracts including the contracts between the user and CSP, and the ones between CSP and CSP.

In this subsection, it shows the intra-cross service that the users’ request can be managed for new services to get better QoS in the same CSP and different DCs. Also, the inter-cross service that the users’ request can be managed for new services to get better QoS from different CSPs based on the contract is described. The required message flows for those functions are given below. In Fig. 5, the intra-cross service requested within the same CSP is presented. Furthermore, the inter-cross service re- quested within distinct CSPs is also presented in Fig. 6.

4 Application scenarios

In this model, three scenarios are suitable for Contract RBAC model in cloud com- puting.

1126 H.-C. Chen et al.

Fig. 5 The message flows for a required of Intra-cross service

Fig. 6 The message flows for a required of Inter-cross service

4.1 Basic application

Assume that there are two CSPs serving as providers and four DCs serving as large RBAC servers. Then, the users u1, u2, u3, u4, and u5 are individually assigned the roles with a relationship satisfying the UA relations UA(A) and UA(B) where the rela- tions are defined according to Definition 5 as follows: u1 ∈ UA(A), u2 ∈ UA(A), u3 ∈

Contract RBAC in cloud computing 1127

UA(A), u4 ∈ UA(A), and u5 ∈ UA(A) where UA(A) ⊆ U (A) × CR(A); Also, u1 ∈ UA(B), u2 ∈ UA(B), u3 ∈ UA(B), u4 ∈ UA(B) and u5 ∈ UA(B) where UA(B) ⊆ U (B) × CR(B). The following case is illustrated.

Scenario 1: The users, u4 and u5 shown in Table 5, are assigned the contract roles cr

(B) 4 and cr

(B) 2 by the CSP

(B), respectively, where the two contract roles satisfy the

ascendancy relation cr(B)2 � cr(B)4 . In other words, according to Definition 6, user u5 could obtain not only a contract role cr(B)2 but also the contract role cr

(B) 4 , and ac-

cess the permissions not only from the contract role cr(B)2 in DC (B) hy1

but also from

the contract role cr(B)4 in DC (B) pv1 as shown in Table 2 and Table 4. On the contrary,

however, the user u4 cannot obtain contract role cr (B) 2 and access the services from

the contract role cr(B)2 as shown in Table 2 and Table 4. This implies that user u4 is assigned to the contract roles as cr(B)4 , that is, user u4 is not assigned to another

contract role. In Table 2 and Table 4, if DC(B) hy1

and DC(B)pv1 authorized by CSP (B)

enforces these two contract roles cr(B)2 and cr (B) 3 , such that these two contract roles

share a SSD relation according to Definition 7. If these two contract roles are con- flicting, user u2 may never activate these two contract roles cr

(B) 2 and cr

(B) 3 , i.e.,

({cr(B)2 , cr(B)3 }, 2) ∈ SSD(B). In Table 2 and Table 4, according to Definition 8, no users are allowed to activate both contract roles cr(B)1 and cr

(B) 3 in a single session,

i.e. ({cr(B)1 , cr(B)3 }, 2) ∈ DSD(A). The fact is that no DSD constraint on cr(B)1 and cr

(B) 3 is specified for the other contract roles. Only DC

(A) 1 and DC

(A) 2 authorized by

CSP(B) enforces the constraint by CSP(A) that user u1 may never activate those two contract roles for a single user’s session based on contract. Finally, after successfully performing a user’s authentication by CSP(k), a user could be allowed to access those DCs.

4.2 Intra-cross services scenario

An intra-cross services scenario in hybrid cloud is described in Fig. 5 in Scenario 2. Scenario 2: User u(B)1 is using a contract role, cr

(B) 1 , to access services at the

serving DC(B)pu1 in public cloud with a hybrid cloud, DC (B) hy1

= DC(B)pu1 ∪ DC(B)pr1 , in CSP(B). Then user u(B)1 needs more services in private cloud DC

(B) pv1 and decides to

activate intra-cross services depending on whether public cloud DC(B)pu1 and private

cloud DC(B)pv1 are existed in the contract with the same CSP (B). Then the user sends

intra-cross services request to the datacenter DC(B)pu1 . After receiving intra-cross ser-

vices request from the user, DC(B)pu1 will deliver the request to datacenter DC (B) pv1 . Then

DC (B) pv1 prepares the requested services and response to the user depending on the con-

tract role; so that, CSP(B) responses the request to the user and the user can access more services in not only public cloud but also private cloud.

1128 H.-C. Chen et al.

4.3 Inter-cross services scenario

An inter-cross services scenario held within the public cloud and private cloud where each cloud belongings to different CSP is described in Fig. 6 in Scenario 3.

Scenario 3: It assumes that there is a public cloud DC(A)pu1 provided by CSP (A)

and a private cloud DC(B)pv1 provided by CSP (B). User u(B)3 is using a contract role

cr (A⊆B) 2 to access services at DC

(B) pv1 , which acts as a private cloud shown in Table 1

and Table 3. Then the user needs more services and decides to activate inter-cross services depending on if the user can access not only the public cloud DC(A)pu1 in

CSP(A) but also the private cloud DC(B)pv1 in CSP (B) in the contract. Then the user

decides to send inter-cross services request to the public cloud DC(A)pu1 in CSP (A).

After receiving Inter-cross services request from the user, DC(A)pu1 will deliver the

request to datacenter DC(B)pv1 in CSP (B). Then DC(B)pv1 will prepare the new services

depending on his contract for the user. Furthermore, the DC(B)pv1 will response the

inter-cross services to the user, so that the user can access new services using cr(A⊆B)2 from DC(A)pu1 in CSP

(A).

5 Performance analyses

There are three comparisons for the performance analyses between the traditional manner and our scheme; see Table 6. Due to a user registering, or accessing the services from a DC of a CSP is always using a traditional manner, which needs face to face or one by one to make a contract with the CSP. It is assumed to be a worse case in the subsection as shown below.

5.1 Registration phase

It assumes that a user wants to register m CSPs, such as CSP(1), CSP(2), . . . , CSP(m). In the worse case in a traditional manner, the user has to send m registration request to each CSP(i), i = 1, 2, . . . , m. In the other words, the user has to make the dis- tinct m contracts of User-to-CSPs with m distinct CSPs, individually. Then the user will be assigned the corresponding m contract roles by the distinct CSPs, which are depending on the m contracts, individually. In our scheme, the user only performs a registration procedure to the serving CSP(k). The user has to make only one con- tract with the serving CSP(k). Then, the user will be assigned the corresponding role, which could be assigned to the contract roles from the serving CSP(k) to m − 1 CSPs depending on the contract of User-to-CSP and the contract of CSP-to-CSPs, where the contract of CSP-to-CSPs is made by the serving CSP to other m − 1 CSPs, indi- vidually.

5.2 Access phase

There are two kinds of access phases for intra-cross services and inter-cross services, which are described as below.

Contract RBAC in cloud computing 1129

Table 6 The comparisons of the performance analyses between the traditional manner and our scheme

Comparison Items Schemes

Traditional manner Our scheme

User registration phase How many contracts made by each user and m CSPs

m 1

How many times of registration procedure

m 1

User Access Phase in Intra-cross Services

How many times of authentication procedure

n 1

How many times of access request n 1

User Access Phase in Inter-cross Services

How many times of authentication procedure

n 1

How many times of access request n 1

Storage Usages

End User How many distinct secret information should be kept

m 1

DCs How many distinct secret information should be kept in DCs during Intra-CSP

λ × n λ

How many distinct secret information should be kept in DCs during Inter-CSP

λ × m × n λ

where m is the number of CSPs; n is the number of DCs; λ is the number of users

1. Access phase in intra-cross services It assumes that a user is accessing some services, after activating the authentication

procedure and access request, via a serving DC in same CSP(k). In the worse case in a traditional manner, for getting the n distinct services, which be supported by the distinct n DCs in same CSP(k), the user then activates n distinct authentication procedures and access sessions via n distinct DCs in same CSP(k), individually. Then the user has to activate the n authentication procedures and access requests to n DCs depending on the m distinct contracts of the CSPs in distinct registration phases. In our scheme, the user only activates an authentication procedure and access request to a serving DC, which could deal with the other sessions of authentication procedure and access to other n − 1 DCs, which is dependent on the contract role constrained by the only one contract of User-to-CSP. 2. Access phase in inter-cross services

It assumes that a user is accessing some services, after activating the authentication procedure and access request, via a serving DC in a CSP(k). In a worse case in a traditional manner, for getting the other n − 1 distinct services, which be supported by the other distinct n − 1 DCs in distinct CSP(i), i = 1, 2, . . . , m − 1, the user then activates n − 1 distinct authentication requests and access sessions via n − 1 distinct DCs in distinct CSP(j ), j �= k, j ∈ {1, 2, . . . , m}, individually. In our scheme, the user only activates an authentication procedure and access request to a serving DC in a CSP(k) which could deal with the other sessions of authentication and access to n − 1 DCs, such as each CSP(i), i �= k, i = 1, 2, . . . , m − 1, which is depending on the only

1130 H.-C. Chen et al.

contract role constrained by the contract of User-to-CSP and the contract of CSP-to- CSPs.

5.3 Storage usages

There are two kinds of storage analyses for the end user and DCs, which are described as below.

1. End user It assumes that a user wants to access n DCs in same CSP(k). In the worse case

in a traditional manner, the user needs to keep n secret information for being chal- lenged by the authentication procedure from each DC, individually. In our scheme, the user keeps only secret information for being challenged by the authentication procedure via serving DC in a CSP(k), which could deal with other n − 1 authen- tication procedures and accesses depending on the contract of User-to-CSP. It as- sumes that a user wants to access n DCs, which are belongings to distinct CSPs, such as CSP(1), CSP(2), . . . , CSP(m). In the worse case in a traditional manner, the user needs to keep n secret information challenged by authentication procedures by n DCs, which are belongings to distinct CSPs, such as DCi of CSP(i), i = 1, 2, . . . , m, individually. In our scheme, the user only keeps one secret information challenged by the authentication procedure via serving DC in the CSP depending on the contract of User-to-CSP, which could deal with other n − 1 authentication procedures within each CSP system to other CSP system depending on the contracts of CSP-to-CSPs.

2. DCs during intra-CSP and inter-CSP It is assumed that there are λ users, which want to access n DCs in the same CSP.

In the worse case in a traditional manner, each DC needs to keep at least λ × n secret information for challenging λ users via distinct λ × n authentication procedures, in- dividually. In our scheme, each DC only keeps λ secret information for challenging λ users by the λ authentication procedures in the same CSP depending on the contract of User-to-CSP.

It is assumed that there are λ users, which want to access n DCs during mInter-CSPs. In a worse case in a traditional manner, each DC needs to keep at least λ × m × n secret information for challenging λ users via distinct λ × m × n au- thentication procedures, individually. In our scheme, each serving DC in a CSP only keeps λ secret information for challenging λ users by the λ users’ authentication pro- cedures and λ DCs’ authentication procedures of the distinct CSP, depending on the contract of User-to-CSP and the contracts of CSP-to-CSPs.

6 Conclusions

In this paper, the generalized Contract RBAC model, which can be applied to cloud computing, is proposed. In the proposed model, a user is constrained by the contract roles, which consists of the Roles of the Datacenter with permissions of services. DC can support the services and act as a large RBAC server. The contract should be made by each CSP individually. The CSP can be the service provider and have full power to manage all his own DCs. However, the Contract RBAC consists of more

Contract RBAC in cloud computing 1131

than one DC and CSP. In the model, it divides into two phases: Contract & Registra- tion Phase and the Access Phase. This paper also proposes the SSD and DSD with a contract roles constraint. The Contract RBAC model depends on the contract made from user’s registration phase and satisfies the requirements, which the user can get more services from the same CSP or the different CSP. Finally, three comparisons for the performance analyses between the traditional manner and our scheme are given. Therefore, the proposed Contract RBAC model can achieve more efficient manage- ment for CCEs. Users can activate the contract roles to get various permissions and access the corresponding services under the contract. Also, it can provide the algo- rithms of continuous services with more flexible management in security to meet the scenarios: intra-cross cloud service and inter-cross cloud service.

Acknowledgements This work was supported in part by Asia University, Taiwan, under Grant 101- asia-28, also by the National Science Council, Taiwan, Republic of China, under Grant NSC 102-2221-E- 468-007.

References

1. Armbrust M, Fox A, Griffith R, Joseph AD, Katz RH, Konwinski A, Lee G, Patterson DA, Rabkin A, Stoica I, Zaharia M (2010) Above the clouds: a view of cloud computing. Commun ACM 53(4):50– 58

2. Arnold S (2009) Cloud computing and the issue of privacy. KM World, 19 Aug 2009, pp. 14–22 3. Carles MG, Guillermo NA, Joan B (2012) Intra-role progression in RBAC: an RPG-like access control

scheme. In: Proc of DPM 2011 and SETOP 2011. LNCS, vol 7122, pp 221–234 4. Chen HC, Marcha AV (2013) A cognitive RBAC model with handover functions in small heteroge-

neous networks. Math Comput Model 58(5–6):1267–1288 5. Chen HC, Wang SJ, Wen JH, Chen CW (2009) Temporal and location-based RBAC model. In: Proc

of the fifth international joint conference on INC, IMS and IDC (MCM 2010), Seoul, Korea, Aug 25–27, pp 2111–2116

6. Chen G, Zhang Y, Song M, Wang X (2009) Cognitive access control in cognitive heterogeneous networks. In: Proc of IEEE international conference on communications technology and applications (ICCTA -2009), pp 707–711

7. Chirag M, Dhiren P, Bhavesh B, Avi P, Muttukrishnan R (2013) A survey on security issues and solutions at different layers of cloud computing. J Supercomput 63(2):561–592

8. Ferraiolo DF, Sandhu R, Gavrila S, Kuhn DR, Chandramouli R (2001) Proposed NIST standard for role-based access control. ACM Trans Inf Syst Secur 4(3):224–274

9. Li W, Wan H, Ren X, Li S (2012) A refined RBAC model for cloud computing. In: Proc of interna- tional conference on computer and information science (ACIS 2012), pp 43–48

10. Sandhu RS, Coyne EJ, Feinstein HL, Youman CE (1996) Role-based access control models. IEEE Comput 29(2):38–47

11. Wan Z, Liu J, Deng RH (2012) HASBE: a hierarchical attribute-based solution for flexible and scal- able access control in cloud computing. IEEE Trans Inf Forensics Secur 7(2):743–754

12. Wang W, Han J, Song M, Wang X (2011) The design of a trust and role based access control model in cloud computing. In: Proc of international conference on pervasive computing and applications (ICPCA-2011), pp 26–28

13. Wikipedia (2013) Cloud computing. http://en.wikipedia.org/wiki/Cloud_computing 14. Yau SS, An HG (2011) Software engineering meets services and cloud computing. IEEE Comput

44(10):47–53

Copyright of Journal of Supercomputing is the property of Springer Science & Business Media B.V. and its content may not be copied or emailed to multiple sites or posted to a listserv without the copyright holder's express written permission. However, users may print, download, or email articles for individual use.