Identity Federation in PerfCloud: an Architecturefor Cloud and GRID Integration

Valentina Casola1, Antonio Cuomo2, Massimiliano Rak3 and Umberto Villano2

1Universita di Napoli Federico II, Dipartimento di Informatica e Sistemistica,via Claudio 21, Napoli 80125, Italy

casolav@unina.it

2Universita degli Studi del Sannio, Dipartimento di IngegneriaPiazza Roma 21, Benevento 82100, Italy{antonio.cuomo,villano}@unisannio.it

3Seconda Universita di Napoli, Dipartimento di Ingegneria dell’InformazioneVia Roma 125, Aversa 81031, Italy

massimiliano.rak@unina2.it

Abstract: Both cloud and GRID are computing paradigms forthe large-scale management of distributed resources, and cur-rently their integration is of great interest. This is typicallyobtained through the Infrastructure-as-a-Service cloud model,which is exploited in the GRID context to offer machines withfull administration rights to users. In this paper the focus ison the security problems linked to the integration of cloud andGRID computing. Adoption of identity federation between dif-ferent security domains is proposed to manage the relation-ship between the user machines and the standard GRID in-frastructure. This solution is experimented within PerfCloud, acloud implementation that exploits an underlying GRID plat-form, evaluating its performance in an environment that in-cludes computing resources leased from a commercial cloudprovider.Keywords: GRID computing, cloud computing, security, identityfederation

I. Introduction

According to the definition by NIST, cloud computing is amodel for enabling convenient, on-demand network accessto a shared pool of configurable computing resources (e.g.,networks, servers, storage, applications, services) that can berapidly provisioned and released with minimal managementeffort or service provider interaction. This cloud model pro-motes availability and is composed of five essential charac-teristics (on-demand self-service, broad network access, re-source pooling, rapid elasticity, measured service), three ser-vice models (IaaS, PaaS, SaaS), and four deployment mod-els (Private, Community, Public, Hybrid) [1]. This can relyon a very high number of different technologies, and has anincredibly large set of possible use cases [2].In this paper the focus will be on the security problems linkedto the integration of cloud computing and GRID comput-ing. The latter is a computing paradigm partially similarto cloud computing, whose most relevant implementations,

Globus [3] and gLite [4], are largely diffused in the scientificcommunity. As computing GRIDs enable access to high per-formance distributed resources in a simple and standard way,they are widely exploited in the e-science world for high per-formance computing tasks.As mentioned above, GRID and clouds have many points incommon, not to mention the use of similar underlying tech-nologies. However, they are typically exploited for differentpurposes by different classes of users. In short, clouds arefor users that are prone to buy computing resources to gettheir results as soon as possible. On the other hand, GRIDusers wish to exploit the optimum number of resources thatsolve the problem, overcoming the boundaries of a single en-terprise. In fact, the two technologies complement gracefullyeach other, and currently their integration is actively investi-gated. At the state of the art, the two principal approachesused are the following:

• GRID-on-Cloud: a cloud IaaS (Infrastructure as a Ser-vice) approach is exploited to build up and to man-age a flexible GRID system [5]. As the GRID middle-ware runs on cloud-managed virtual machines, the maindrawback of this approach is performance. Virtualiza-tion inevitably entails performance losses as comparedto the direct use of physical resources.

• Cloud-on-GRID: the well-known and stable GRID in-frastructure is exploited to build up a cloud environ-ment. This is usually the preferred solution [6], becausethe cloud approach mitigates the inherent complexityof the GRID. The use of Globus workspaces [6], alongwith a set of GRID services for the Globus Toolkit 4 isthe prominent solution, as in the Nimbus project [7].

The cloud-on-GRID approach has gained large interest in thescientific community, as it helps to manage some of the mostcommon problems with parallel programming: the incrediblevariety of different softwares (and software versions), con-

Journal of Information Assurance and Security ISSN 1554-1010 Volume 6 (2011) pp. 311-321© MIR Labs, www.mirlabs.net/jias/index.html

Dynamic Publishers, Inc., USA

Figure. 1: The gridcloud layers

figurations, operating systems and hardware layers that oftenhave to coexist, but are not mutually compatible. Thanks tothe adoption of clouds, and of their underlying virtualizationtechniques [8, 9, 10] it is possible to provide GRID users andparallel application developers with a “clean” environment,freely and completely customizable. Current cloud-on-GRIDsystems [7, 11, 12] offer services to manage (create, destroy,modify, . . . ) virtual clusters (i.e., clusters composed of vir-tual computing resources) on the underlying GRID infras-tructure.In a “pure” cloud-on-GRID system, the virtualized environ-ments assigned to users are mutually isolated, and do notknow of each other. Given two scientific communities work-ing on different, but related problems, the users of each grouphave access to a freely-customizable computing platform, butcannot invoke the software services developed by the othergroup. Even if their computing environments exploit physi-cally the same GRID, they are not interoperable.In PerfCloud, an existing cloud-on-GRID infrastructure withprovision for predictive performance evaluation [13, 12], thisproblem is solved by integrating the virtual resources offeredby the cloud into the underlying GRID. In other words, givenan existing computing GRID, users can gain access to virtu-alized resources (e.g., virtual clusters) through a cloud inter-face, and these virtual resources are integrated in the existingGRID and can cooperate with its physical (and virtual) com-ponent systems. Stated another way, the virtual clusters pro-vided by the cloud are automatically part of the underlyingGRID infrastructure. This approach, which we call cloud-grid, achieves full cloud and GRID integration. It is a sortof three-layered “GRID-on-cloud-on-GRID” (Figure 1). Ifone looks only at the two upper layers, it can be regarded asa GRID-on-cloud system. Looking at the two layers at thebottom, it is instead a cloud-on-GRID system.It is worth pointing out that the virtual resources integrated inthe GRID by PerfCloud can be provided by either a privatecloud made on the top of GRID resources, or by a commer-cial cloud provider. Moreover, the two solutions can coex-ist. In this case, the cloud layer is of “federated nature”, inthat it is made of resources that in part come from the un-derlying GRID layer, and in part are leased from an externalcommercial cloud provider like Amazon EC2. The cloud-

grid approach completely hides the origin of the computingresources, since at the highest layer there is the perception ofa single, uniform, GRID infrastructure.As a matter of fact, Cloudgrid is an almost obvious approachto solve the interoperability problem discussed above, but en-tails big security issues. These issues are stressed by the useof leased cloud resources, as will be done in the experimentspresented this paper. In practice, any virtual cluster adminis-trator, who is for the GRID a standard user with no physicalresource management grants, can act as a GRID administra-tor once the virtual cluster is integrated in the GRID. Fur-thermore, in the cloud environment, the cooperation amongvirtual resources is desirable and the extension of trust to un-trusted users through identity federation is still an open issue.The objective of this paper is to tackle these cloudgrid secu-rity issues. We propose a solution where any virtual clusteradministrator configures a new and independent security do-main (and a new Certification Authority), granting its accessto the underlying GRID infrastructure and to virtual clustersthrough an Identity Federation mechanism. In other words,the virtual cluster will build up a completely new securitydomain, managed independently by the cloud user. Succes-sively, a federated security domain will be built between thevirtual cluster domains or with the underlying GRID. In ac-cordance with the basic principles of the cloud-oriented ap-proach (and most notably, with the on-demand self-servicecharacteristic), the identity federation problem, usually man-aged manually, will be completely automatized thanks to theintroduction of an Interoperability System that does not re-quire human intervention. The proposed architectural solu-tion has been implemented for PerfCloud and will be pre-sented as a case study; nevertheless, it has a wider validity,as it can be adopted for every GRID-on-cloud implementa-tion.The remainder of this paper is organized as follows. The nextsection briefly introduces PerfCloud, the proposed cloudgridinfrastructure and its security issues. In Section III the iden-tity federation problem in GRIDs is dealt with, and it is de-scribed an interoperability system that allows cooperationamong untrusted domains. Section IV presents an implemen-tation of the interoperability system for Identity Federationin clouds. In Section V we will show an analysis whose goal

312 Casola et al.

Figure. 2: The PerfCloud architecture

is to ascertain if the adoption of the interoperability systemand/or the use of virtual machines leased from a commer-cial cloud (Amazon EC2) can affect the global system per-formance. The paper closes with the conclusions and thepresentation of future work.

II. PerfCloud and Security issues

PerfCloud [12] is a cloudgrid implementation, offering ser-vices for the creation and management of virtual comput-ing resources (virtual clusters) on the top of a computingGRID. The cluster-on-demand functionalities are integratedwith a simulation environment able to predict user applica-tion performance on the newly instantiated virtual clusters,which are automatically integrated in the existing GRID. Per-fCloud builds a IaaS (Infrastructure-as-a-Service) cloud en-vironment upon a Globus GT4 GRID infrastructure. Theresources offered to users by the PerfCloud system are vir-tual clusters, i.e., sets of preconfigured virtual machines con-nected by a (virtualized) network. The cloud user owns suchsystems and has administration rights on them, but he cannotmanage the physical resources.Figure 2 describes the overall architecture of PerfCloud.The PerfCloud application client resides on a user machine(which has access to the GRID environment) and interactswith the PerfCloud system by invoking GRID services. Fur-thermore, it manages GRID connections, also providing util-ities for end-users (notably, the above-mentioned perfor-mance analysis services). The architecture provides differentGRID services that enable the user to build up a new clusteras a GRID Virtual Workspace [6] with full access rights. Inlight of the above, the PerfCloud architecture can be subdi-vided into three main components, as is shown in the figure:

• Service Oriented Interface, the set of (GRID) servicesthat offer the PerfCloud functionalities to the GRID en-vironment. The offered services vary from Cloud IaaSServices (offering Virtual Machine (VM) and VirtualCluster (VC) management services) to added-value ser-vices for performance evaluation;

• Image Catalog, which are the Virtual Cluster (VC)Node images, containing all the software needed to in-tegrate the VC into the GRID environment (a Globuscontainer) and to offer services to the final user (a set of

Globus Services deployed on the VC container), alongwith other software needed for application developmentand execution (compilers, messaging libraries and run-time support, . . . )

• Client, an extensible client which allows the final usersto interact with the Cloud environment;

As shown in the figure, the virtual clusters host a Globuscontainer on the virtualized cluster front-end, together with aset of predefined services. Further details on the PerfCloudimplementation can be found in [13, 12].In a previous paper [14] we have enhanced PerfCloud witha role-based access control mechanism to authorize accessto the resources offered by the framework. In particular, weidentified the following set of roles for the users of the cloud-grid system:

• System Administrator manages the physical machinesfrom HW up to the operating system level. He is alsoresponsible for installing, configuring and starting theGlobus platform and for managing identities and ac-counts (issues digital certificates, enables users);

• GRID User can access and use generic GRID re-sources;

• Cloud User is a GRID user with special rights for ac-cessing and using Virtual Cluster and Virtual MachinesGRID resources;

• Cloud Administrator is a GRID User with specialrights for creating new Virtual Clusters and managingthe rights of the cloud users.

It is interesting to point out that the cloud administrator doesnot have administrator rights on the virtual cluster, which areowned by the cloud user. A cloud administrator is insteadable to create a new set of virtual clusters and to offer themto different cloud users. It should be noted that once a virtualcluster set exists and is assigned to a cloud user, the data andconfiguration of the VC are his private property.Even if offering full rights on the virtual cluster is one of theaims of clouds, this can have a side effect on the cloudgridapproach. In fact, the VC administrator has full right accessto the VC and he can also manage the new GRID site that is

313Identity Federation in PerfCloud: an Architecture for Cloud and GRID Integration

hosted by the physical GRID site. This represents a big se-curity issue. An user of an hosted site could access physicalresources if the cloud administrator does not enforce propersecurity policies in issuing credential or delegating rights, orif it wants to abuse of his role on the physical resources. Fur-thermore, to fully enable the cloud approach, it is desirableto grant cooperation among virtual resources even when theyare offered by potentially untrusted domains.This problem cannot be solved only by an access controlmechanism. At the state of the art, when a GRID infrastruc-ture has to accept a new virtual site as part of the infrastruc-ture, usually a complex procedure takes place. This involveshuman interaction and manual evaluation of the security poli-cies adopted by the site to enable cooperation and to trusteach other. But, as one of the objectives of any cloud sys-tem is to automatize all procedures (on-demand self-service,according to NIST document [1]), the safe “manual” GRIDadmission procedure is not a reasonable solution.In the rest of this paper, we will describe the proposal ofan interoperability system that provides an automatic way toimplement the Identity Federation concept and to assign spe-cific roles to “federated” users.

III. Identity Federation in GRIDs

Our approach to manage the security issues that arise fromthe integration of the Virtual Cluster in the underlying GRIDlayer is based on two key points: (i) a Cloud administratorbuilds up a new Virtual Organization for each Virtual Clusteras an independent security domain (i.e., with its own Certifi-cation Authority), (ii) an identity federation is implementedto enable an automatic interoperability among a Virtual Clus-ter and the physical Grid site or between two Virtual Clusters.A Cloud user will be able to customize the Certification Au-thority of its Virtual Cluster, or even to setup a completelynew one.In order to describe clearly the problem, we summarizehere how the authentication process takes place in a GRIDenvironment (or in a cloud-on-GRID, which is the same).In a cloud environment, users possess a set of Grid cre-dentials consisting of a X.509 v3 digital certificate [15]and a private key. The certificate is digitally signed by aCertification Authority that guarantees for the binding ofthe entity distinguished name (DN) to its private key. Theauthentication mechanism involves the presentation of thecertificate and the possession of the corresponding privatekey. A known problem in such a protocol is the protectionof the private key. At this aim, two strategies are commonlyadopted: i) the key is protected with encryption or bystoring it on a hardware token (e.g., a smart card); ii) the pri-vate key has limited lifetime, after which it is no longer valid.

The Globus Toolkit security implementation, known as theGRID Security Infrastructure (GSI) [16], follows the secondstrategy, using Proxy Certificates [17]. Short-term creden-tials created by a user can successively be used in the placeof traditional long-term credentials to authenticate him. Theproxy certificate has its own private key and certificate, and issigned using the user long-term credential. A typical sessionwith the GSI would involve the GRID user (End-Entity) us-ing its passphrase and the GSI command grid-proxy-init cre-

ating a proxy certificate from its long-term credential. Theuser could then use a GSI-enabled application to invoke aservice operation from a Globus Toolkit GRID Services Con-tainer [16].From the GRID resource point of view, to fully perform theauthentication process, a certificate validation service inter-face should be defined and used within the Open GRID Ser-vices Architecture (OGSA) [18] implementation to:

1. parse a certificate and to verify desired attribute values,as the validity period, the Distinguished Name and soon,

2. perform path validation (basic and extended) [15] ona certificate chain and verify the revocation status ac-cording to updated certificate revocation lists (CRLs) orthrough an on-line Certificate Status Protocol,

3. return attribute information for different usage.

Available GRID implementations, as the Globus Toolkit(GT4) [1], provide static mechanisms to perform a basic cer-tificate path validation process, i.e.:

1. Cryptographic verifications over the certificate path(verifying the digital signature of each certificate).

2. Verification of each certificate validity period.

3. Verification that the root certificate in the chain istrusted.

4. Verification of the certificates status to ensure that theyhave not been revoked or suspended.

In particular, in GT4 the first certificate in the chain is con-sidered a Trust Anchor if it has been stored into the GRIDnode /etc/grid-security/certificates/ direc-tory, while the certificate status is retrieved from a locally-stored Certificate Revocation List (CRL).To validate a digital certificate issued by any other CA, an ex-plicit cross-certification process is needed and the so-called“extended path validation” [15] must be enforced. The mainidea behind the extended path validation mechanism is to de-fine an approach that enables any GRID relying-party to val-idate in real-time a digital certificate issued by any other CA,even if they do not belong to the same trusted domain. So,there is also the need to evaluate and to extend trust to theauthority that issued such certificates. In the GRID environ-ment, if we are able to automatically perform the extendedpath validation, we are able to perform Identity Federationsince we can accept and validate credentials from any do-main. Our approach is to build a dynamic federation of CAsby automatically evaluating their certificate policies (auto-matic cross-certification) [19].In Figure 3 the logical blocks of the Interoperability System(IS) are shown. It acts as an intermediary between the certifi-cate verifiers (relying parties) and the issuing CAs by man-aging (retrieving, elaborating and updating) the informationneeded to perform the extended path validation: the list ofaccredited CAs, the list of revocation sources and the Certifi-cate Policies.The IS may be allocated within the Trusted Third Party do-main. In our case, it will be offered as a service by the Phys-ical GRID site, and must perform two main tasks: 1. on-line

314 Casola et al.

Figure. 3: Interoperability System (IS) main components

validation of the certificate status, 2. evaluation of the issuingCA security level.For the first task we will use a GRID Validation System ableto retrieve the status of a digital certificate through the OCSPprotocol in a CA federation. This feature has been imple-mented as an extension of Globus Toolkit, and it is namedOGRO [20, 21]. As regards the second task, for evaluatinga CA security level we have adopted the Reference Evalu-ation Methodology (REM), a policy-based evaluation tech-nique that was primary proposed for evaluating CertificationAuthorities in the cross-certification process [19].The REM approach is based on the formalization of a GRID-CA Certificate Policy i) to determine if this Authority is com-pliant with another CA Certificate Policy and ii) to quantita-tively evaluate the Global Security Level (GSL) of this CA.The GSL is a quantitative measure of the CA trust degree,and it will be compared with the other CA level to decide toextend or not the trust to an incoming user request. The GSLwill be retrieved and evaluated by a GRID Service before ex-tending trust (to federate an identity).In [22] we proposed a Interoperability System based on Pol-icy evaluation and on the OCSP protocol (POIS), in next sec-tion we will illustrate how it can be adopted in a Cloud-on-GRID environment to enable Identity Federation.

IV. Identity Federation in PerfCloud

In this section we illustrate the use of the Policy and OCSPbased Interoperability System (POIS) to enable Identity Fed-eration among cloud users. Figure 4 shows the main actorsand the system components that have an active role withinthe PerfCloud framework during the invocation of a serviceoffered by a Grid container that supports federation (Feder-ated Grid Container).At a coarse view, POIS offers the following features:

1. Manages (retrieves, updates) the list of Virtual Organi-zations CAs (accredited by the root-VO).

2. Manages (retrieves, updates) the accredited CAs Certifi-cate Policies.

3. Manages (retrieves, updates) the accredited CAs CRLs.

4. Communicates validation information to relying partiesover OCSP.

As for the features 1 and 2, we assume that the databasewith the list of accredited CA and their Certificate Policies ismanually and off-line managed by system administrators (inparticular by the GRID Administrator). The CRLs (feature3) from each accredited CA are retrieved by using CertiVeRCRL Updater module (described in [23]), so they can be usedin the Extended Path Validation process. The Policy Evalua-tor subsystem implements the REM evaluation technique toevaluate the GSL on any VO CA Policy. The GSL is thencommunicated to relying parties by the OCSP protocol (fea-ture 4).To summarize, POIS is able to perform the Extended PathValidation thanks to a specific client (like OGRO [24]) whichprovides the following two enhancements to the GT4 basicpath validation algorithm: i) certificate status is extractedfrom the OCSP response and ii) the GSL evaluated by POISis compared against the GSL value required by the Grid Ser-vice for trusting the request from a different Virtual Organi-zation.We wish to point out that it is up to the Grid Container to in-teract with the Interoperability System. It can perform suchan operation if and only if a suitable client has been added(possibly OGRO). We will denote such container as a Fed-erated Grid Container (and, consequently, we will refer toFederated GRID Services and Federated Resources). Whena customer asks for a Virtual Cluster, the Cloud Administra-tor will create a new Virtual Cluster and configure imagesand services with or without federated facilities according tothe customer desiderata.Once federated services are available, different scenariosmay occur. They are strictly related to the relations betweenthe different Virtual Organizations. In particular:

1. the new Virtual Cluster has a pre-configured Certifica-tion Authority that has a hierarchical relation with theRoot Certification Authority of the Physical Cluster;

2. the new Virtual Cluster CA has not any relations withthe other Virtual Clusters or with the Physical Cluster.

In the first case, basic path validation is enough to ex-tend trust to cloud users whose certificates have been issuedwithin the hierarchy (the Certification Path validation pro-cess does not fail as the Root CA acts as the Trust Anchor).Nevertheless, the adoption of a hierarchical approach shouldbe discouraged (i) to enable Cloud Administrators to config-ure their own Certification Authorities and (ii) to avoid thata Cloud Administrator issues to its users digital credentialsthat can be directly validated and accepted by all physicalgrid resources.In the second case, an explicit federation mechanism isneeded to cooperate. Identity Federation does not automati-cally mean to grant access to a federated resource. In fact,once a user has been authenticated by an external VirtualCluster, its identity will be mapped to a specific (federated)role and a role-based access control policy will be enforcedat resource level [14]. For example, a user from the VirtualCluster 1 that has a role of Cloud Administrator can accessto specific resources of Virtual Cluster 2 but, possibly, with anon-administrator role.

315Identity Federation in PerfCloud: an Architecture for Cloud and GRID Integration

Figure. 4: Service request to a Federated Grid Service through POIS

In the following, we will describe in detail the second sce-nario, including the role mapping and authorization aspects.

A. A case study scenario of access to Federated Resources

Figure 5 shows a typical scenario, where a cloud user belong-ing to the Virtual Cluster 1 (denoted user@VC1 from Vir-tual Organization 1) requests a GRID service offered by thephysical cluster (FGC@Root within the Root Virtual Orga-nization). The interoperability is achieved because the GRIDServices Container has been federated.To let POIS work in an off-line manner, any CA from thedifferent Virtual Organizations submits its Certificate Policy(CP) to the POIS. Then, the Policy Evaluator subsystem eval-uates the corresponding GSL that is stored into OCSP Re-sponder DB along with the CA data (this step is not shownin the diagram).

Figure. 5: Extended Path Validation with POIS

The main steps of this scenario are:

1. When a Cloud user from the Virtual Cluster 1(user@VC1) requests a GRID service offered by the

Table 1: Roles mapping

Requester Req. Resource VO Identity mechanism Role mappedUser@VC1 Root ext. valid. feder. lim. userUser@VC1 VC2 ext. valid. feder. userUser@Root Root basic valid. sameUser@VC1 VC1 basic valid. sameUser@Root VC1 ext. valid. feder. user

Root Virtual Organization, the Federated Grid Con-tainer (FGC@Root) performs extended path validation:

• basic path validation on the proxy certificate isperformed;

• the digital certificate status is evaluated on-linethrough the OCSP Responder;

• the GSL value is directly retrieved from the POIS(that holds a database with all pre-evaluated Certi-fication Authorities of the accredited Virtual Clus-ters).

• the GSL of the Cloud user’s CA is comparedagainst the minimum required-GSL defined by theFederated Grid Container to extend trust, and ifGSLV C1 > GSLGC , the validation is successful.

2. If the extended path validation is successful, the clouduser is mapped to a “federated user”. Before access-ing the requested resource, the corresponding role is re-trieved by a role repository and a role-based access con-trol mechanism is enforced by using an external Pol-icy Decision Point (PDP) configured at Resource Level[16].

In Table I, we report different cases of federation and thecorresponding “federated role” that is assigned consideringwho requests a resource and where the resource is hosted.We can note that if an user from VC1 requests a service ofthe Root VO, it is recognized as a federated limited user anda limited set of rights will be granted in the rbac policy (for

316 Casola et al.

example, we could grant computing resources, but not ad-ministration ones). If the same user from the VC1 requests aservice of the VC2, it will be recognized as a federated userand the rbac policy will grant services according to the agree-ments between parties. If a user from the root VO (or a userfrom VC1) requests a service of the Root (or of the VC1) -this is a trivial case - basic path validation is performed andthe user role does not change being the requester not feder-ated but ”internal” and this not requires the extended valida-tion mechanism. The last case is when a user from the RootVO requests services offered by a VC. Once again, extendedpath validation is performed and the assigned role and thepolicy will depend on the agreement between the parties.In conclusion, thanks to the Interoperability System we areable to extend trust to cloud users even when they come fromuntrusted domains. The whole mechanism works because weare able to automatically validate any digital certificate and toassign it a degree of trust (the Global Security Level). On thebasis of this trust degree, we are also able to assign a dynamicprofile to users coming from the outside world, to let themaccess to computing or even administration resources. Thisis a very important point in a cloud environment, as identityfederation is an open issue that still limits the wide adoptionof these infrastructures.

V. Performance Evaluation

In this paper we have shown how to build up a federatedcloudgrid system using both physical servers and virtualmachines. The latter can obtained from a locally-availablevirtual cluster, or even be leased from a commercial cloudprovider. The result is a single GRID infrastructure thatmixes up physical, virtual and cloud-based machines. Per-fCloud users can add clusters of machines obtained, for ex-ample, from Amazon EC2, to an existing GRID infrastruc-ture in a simple and secure way. The experiments reportedin this section aim to spot any possible performance problemlinked to the adoption of this approach.In a previous paper [25] we presented an analysis whose goalwas to evaluate the performance of different authenticationand authorization mechanisms in “traditional” GRID envi-ronments (Globus Toolkit) deployed in physical or virtualmachines. The main result of that analysis was the identifica-tion of an optimal set of parameters for setting up the system,along with some practical considerations about the design ofcloudgrid systems.In the following we assume that cloudgrid system is op-timally configured (i.e., configured following the designguidelines from [25]). Our aim will be to understand if andhow the adoption of the POIS interoperability system and/orthe use of virtual machines leased from a cloud can affect theglobal system performance.

A. Performance Evaluation Methodology

Our performance evaluation aims at measuring the responsetime of the system as a function of the location of the dif-ferent entities involved (clients, servers, interoperability sys-tem), i.e., depending on whether they are hosted in a localnetwork or leased from a commercial cloud provider (EC2).To enforce the extended path validation needed to evaluate

the impact of federation, we reduce the number of entities tothree: a server container hosting business services, an inter-operability system trusted by the server, and a client whoseidentity is not known to the server but is certified by the inter-operability system. In light of the above, the factors affectingperformance and their N possible values (levels) are the fol-lowing:

• Client Location (N=2), which can be Local network orEC2;

• Server Location (N=2), which can be Local networkor EC2;

• POIS Location (N=2), which can be Local network orEC2.

Since the number of different factors and levels is very low,we decided to perform a full factorial design of experiments[27], in which every possible combination of both levels ofall factors is considered. This allows us to find the effect ofevery factor, including the secondary ones, and their interac-tions. In this peculiar case, where all factors are restricted toassume only two possible levels, the design is termed as 2k

factorial and, as we will show below, the analysis is relativelysimple.Besides the chosen factors, it is also important to specify theother system and workload characteristics that may affect theperformance of the system, but that have been constrained toassume a single, fixed value. These are generally called sys-tem parameters. Treating a feature as a parameter and not asa varying factor depends from various considerations, includ-ing the cost of the analysis and the nature of the feature; inour case, we chose some fixed parameters according to pre-vious analysis on the impact of different security solutions tothe overall performances, as discussed in [25].Basically, adding more factors to the system analysis impliesperforming more experiments; stated another way, the num-ber of factors must be limited to keep the analysis tractable.Hence if a feature is thought not to be very relevant to thesystem performance, it should be considered a parameter. Asecond reason to treat a feature as a parameter is that it can-not be easily varied (for example, it is a hardware resourcethat cannot be configured). In this case, it must necessarilybe treated as a fixed-value parameter. In our case, the mainsystem parameters, we chose, are:

• Testbed configuration: A virtual machine is set up forevery entity of the system (client, server, interoperabil-ity system). In the local configuration, each virtual ma-chine is instantiated on a Xen-equipped physical hostof the local cluster. In the case of the EC2 configura-tion, every virtual machine is actually an EC2 VirtualMachine.

• Authentication mechanisms: The server always com-municates with the interoperability system throughHTTPS. The client communicates with the serverthrough a message-level security (WS-Security) proto-col in which the server-side has been adapted to performextended path validation. In this case, the underlyingprotocol is plain HTTP.

317Identity Federation in PerfCloud: an Architecture for Cloud and GRID Integration

• Authorization mechanisms: The interoperability sys-tem enforces the standard grid mapfile to authorize itsclients. The server enforces the XACML mechanismdescribed in [25].

• Invoked Service: To simulate a core business service,we have developed a synthetic PerfCloud NULL ser-vice, which sends just a short reply message when in-voked.

• Message size: The size of messages exchanged by theNULL service is very short (of the order of tens of bytes,plus the SOAP envelope).

The objective of the well-known methodology presented in[27] is to define a model that takes in consideration differenteffects until the evaluated error is negligible. The contribu-tions to the system response that come from a single factorare called main effects, and those that come from the mutualfactor interaction are called interaction effects. Both have tobe taken into account until the model error (meant as differ-ence between the measured value and the value predicted bythe model) can be considered negligible. In the next subsec-tions, we will detail the construction of such model.

1) Conduct of experiments

To perform the required experiments, we set up Xen vir-tual machine images for each of the involved entities (client,server, interoperability system). Both the interoperabilitysystem and the server are hosted in Globus Containers pro-vided by the Globus Toolkit version 4.0.8. The interoper-ability system virtual machine contains an HTTPS Globuscontainer hosting the federation management service. Theserver machine hosts an HTTP Globus Container providingthe NULL Service described in subsection V-A and an inter-operability client able to contact the interoperability system.The client machine contains a client for the NULL Service.Local machine instantiation was performed on the Power-COST Cluster, which is a 40-nodes cluster made of IntelXeon-based biprocessor nodes with 2 GB RAM, intercon-nected through a Fast Ethernet network. The O.S. is RocksCluster version 5.1, which is based on Linux CentOS 5 up-date 2. The virtual machines are instantiated on some nodesof the cluster configured for virtual machine hosting (virtualmachine containers in Rocks terminology).The virtual images have also been packed and stored in theAmazon Simple Storage Service (S3), thus making it possi-ble to instantiate the virtual machines also on EC2. On thisplatform, we chose to instantiate EC2 Small Instances [26].In brief, each Small Instance is powered by a single proces-sor, which is a virtualized core of an Intel Xeon E5430, with1.7 GB of RAM and an I/O performance that, according toAmazon performance metrics, is rated as Moderate.In accordance with the design of experiments, every possiblecombinations of all levels of all factors has been evaluated.Every test follows the same sequence of interactions, de-scribed hereinafter. The client starts by invoking the NULLservice on the server. When the service receives the request,it has to validate the client identity according to the message-level security protocol augmented with the extended path val-idation described in section IV. Since the client is not au-

thenticated by the server CA, the server contacts the Interop-erability System to perform the authentication. If the clientidentity is registered at the interoperability system (as in ourcase), the POIS Server performs the validation and the serveris able to decode the message, to perform the actual serviceexecution and to send the answer back to the client.Since the service response time is not deterministic, the clientperforms I invocations of the (NULL) service and records ina database the response times, on which statistical analysiscan be applied. To collect a statistically significant numberof measurements, I was set to 50. Every I-invocations ses-sion was repeated three times, and we chose the session withthe lowest standard deviation, discarding the other two. Forthe chosen session the final output consisted of the mean, thestandard deviation and the confidence interval for the exper-imental points.

B. Experimental Results and Model Evaluation

Table 2 shows the response times corresponding to every pos-sible combination of the chosen factors at all levels. The firstcolumn will be used to identify a specific combination in thefollowing discussion.Once the experimental results have been obtained, the nextstep of the analysis is the definition of a model taking in con-sideration the main effects of each factor (the contributionsthat come from a single factor) and the interaction effects(the contributions that come from the mutual interaction ofn-ples of factors). This leads to the following model:y = q0 + qCCi + qSSj + qP Pk + qCSCSij + qSP SPjk +qCP CPik + qCSP CSPijk

where i=(Local, EC2), j=(Local, EC2), k=(Local, EC2), C,S, P (respectively Client, Server and Pois location) are thefactors considered and their combinations represent the inter-action effects. The value of Factorindex is “−1” if index =Local , “1” if index = EC2. The q are the model coefficientsthat will be derived from the analysis of main and interactioneffects: in particular, q0 is the global mean (i.e., the averageof all values). For 2k factorial design, the main effects andinteractions can be computed easily by using the sign tablemethod [27].After deriving the model coefficients, the analysis proceedsby computing the allocation of variations, which allows toascertain how much factors or their interaction weight on thetotal measured value. The results are reported in table 3.The final step is the model validation, which can be con-ducted by visual analysis. Figure 6a is a visual plot of theresiduals as a function of the predicted response, which doesnot show any particular evidence of trends that contradict theassumption of independent errors. Figure 6b shows a Normalquantile vs. quantile plot, in which the close correspondenceto a straight line confirms that the errors are normally dis-tributed with zero mean and a constant standard deviation.

C. Performance Considerations

The analysis of the previous section reveals interesting in-formation on the system performance behavior. In practice,the impact of the single factors is negligible. This was tobe expected, since our factors representing system compo-nents placement are inherently interdependent (the impact of

318 Casola et al.

Table 2: Response times and their confidence intervals for the different resource placement(ms)

Combination # Client Location Server Location POIS Location Response time1 Local Local Local 852.32 [841.69, 862.95]2 Local Local EC2 1619.4 [1609.09, 1629.71]3 Local EC2 Local 2220.1 [2196.63, 2243.57]4 Local EC2 EC2 1357.62 [1341.48, 1373.76]5 EC2 Local Local 1495.96 [1481.68, 1510.24]6 EC2 Local EC2 2270.4 [2257.03, 2283.78]7 EC2 EC2 Local 1639.14 [1615.27, 1663.01]8 EC2 EC2 EC2 763.9 [747.61, 780.09]

Table 3: Sum of Squares for the different components

Component Sum of Squares Percentage of Variation (%)y 1040593976y 933125318.41

y − y 107468657.59 100.00C 89940.01 0.08S 413834.89 0.39P 240590.25 0.22

CS 38109632.89 35.46CP 182.25 0.00SP 67208843.61 62.54

CSP 2530.09 0.00Errors 14031036 1.31

(a) Residual vs. predicted plot. (b) Normal quantile-quantile plot.

Figure. 6: Residual Analysis

319Identity Federation in PerfCloud: an Architecture for Cloud and GRID Integration

the location of one component depends on the location ofthe others). The performance figures in table 3 show thatthere is a higher dependence on the Server-Pois (SP) inter-action (62.54 %) than on the Client-Server (CS) interaction(35.46%). This is an issue that an efficient placement of theresources must take in account. In fact, we can see that theconfigurations where the Server and Interoperability Systemare placed in different networks (corresponding to combina-tions 2, 3, 6, 7 in table 2) obtain the worst response time.Slightly better results are observed when the client and theserver are in different networks, as in combinations 3, 4, 5,6. The joint effect of these interactions is observed in com-binations 3, 6, which correspond to the two longest responsetimes. Shorter response times (1, 4, 5, 8) are observed whenthe server and the POIS are kept in the same infrastructure.The two shortest ones correspond to the case in which themachines are all placed on local network or on EC2 (1, 8).The above observations can be translated in design guide-lines: when a federated system is to be designed, it is betterto “keep together” the servers and the interoperability systemthan client and servers.It is worth pointing out that these considerations do not takein account the size of the messages exchanged among the in-teracting parties, size that has been considered as a systemparameter. Of course, the scenario might change in the pres-ence of messages of different sizes (notably, for large ones).Further tests that will consider message size as a factor withdifferent levels are in our plans for future research.

VI. Conclusions and Future Work

One of the main security issues for the cloud community isidentity federation. Many cloud solutions leverage severalservices without integrating identity management and accesscontrol mechanisms.In this paper we have presented a solution to some open se-curity issues in cloud architectures and, in particular, in Per-fCloud, a framework which offers cloudgrid functionalities.We have focused our attention on the need of users to ac-cess both virtual and physical grid sites without abusing theprivileges linked to their role in their own domain. The pro-posed Identity Federation approach is based on the definitionof an Interoperability System that validates certificates by dy-namically performing a Cross Certification among untrustedCertification Authorities (we adopted the REM methodologyto evaluate and compare the trust level of a Certification Au-thority) and by evaluating on-line the status of a digital cer-tificate (we proposed the adoption of the OCSP protocol anda Grid OCSP client named OGRO). To illustrate in detail theproposed architecture we have presented a case study andsome typical scenarios where users from a virtual cluster re-quest resources hosted by other clusters (virtual or physical),illustrating the federation process and the enforcement of ac-cess control policies that are specific of “federated users”.As regards the future evolution of our work, we intend to in-tegrate the Interoperability System with different authoriza-tion services (as XACML, PERMIS or ShibGRID) to eval-uate the trade-off between the security level provided andoverall system performance. This will make it possible forthe cloud to offer guarantees on the quality of service and tonegotiate Service Level Agreements in an automatic way.

Acknowledgments

The authors acknowledge support from MIUR, PRIN 2008project “Cloud@Home: a New Enhanced ComputingParadigm”.

References

[1] Peter Mell and Tim Grance, “TheNIST definition of cloud computing,”http://csrc.nist.gov/groups/SNS/cloud-computing/cloud-def-v15.doc, 2009.

[2] Doug Tidwell and et al., “The cloud com-puting use case,” http://cloud-computing-use-cases.googlegroups.com, 2010.

[3] I. T. Foster, “Globus toolkit version 4: Software forservice-oriented systems,” J. Comput. Sci. Technol.,vol. 21, no. 4, pp. 513–520, 2006.

[4] E. Laure et al., “Programming the Grid with gLite,”CERN, Geneva, Tech. Rep. EGEE-TR-2006-001, Mar2006.

[5] L. Cherkasova, D. Gupta, and A. Vahdat, “Optimizinggrid site manager performance with virtual machines,”in In Proc. of the 3rd USENIX Workshop on Real LargeDistributed Systems (WORLDS06), 2006.

[6] I. Foster, T. Freeman, K. Keahey, D. Scheftner, B. So-tomayor, and X. Zhang, “Virtual clusters for grid com-munities,” in CCGRID. IEEE Computer Society, 2006,pp. 513–520.

[7] University of Chicago, “Nimbus project,” 2009,http://workspace.globus.org/clouds/nimbus.html.

[8] P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris,A. Ho, R. Neugebauer, I. Pratt, and A. Warfield, “Xenand the art of virtualization,” SIGOPS Oper. Syst. Rev.,vol. 37, no. 5, pp. 164–177, 2003.

[9] VMWare Staff, “Virtualization overview,” WhitePaper, http://www.vmware.com/pdf/virtualization.pdf.

[10] A. Gavrilovska et al., “High-performance hypervisorarchitectures: Virtualization in hpc systems,” in Proc.of HPCVirt 2007, Portugal, Mar 2007.

[11] Purdue University, “Wispy project,” 2009,http://www.rcac.purdue.edu/teragrid/resources/\#wispy.

[12] V. Casola, M. Rak, and U. Villano, “Perfcloud:Performance-oriented integration of cloud and grid,” inProc. of CloudComp 2009, Munich, Germany, October2009, 2009.

[13] E. P. Mancini, M. Rak, and U. Villano, “Perfcloud:Grid services for performance-oriented development ofcloud computing applications,” in Proc. of EmergingTechnologies for Next generation GRID (ETNGRID-2009/WETICE-2009), 2009.

320 Casola et al.

[14] V. Casola, R. Lettiero, M. Rak, and U. Villano, “Accesscontrol in cloud on grid: the Perfcloud case study,” inIn the Proc. of SPCC2010, Bruxelles, 2010, 2010.

[15] Housley R., et. al. Internet Engineering Task Force,“Rfc3280 internet X.509 public key infrastructure cer-tificate and certificate revocation list (crl) profile,”2002, www.ietf.org/rfc/rfc3280.txt.

[16] The Globus Security Team, “Globus toolkit version 4grid security infrastructure: A standards perspective,”2005, www.globus.org/toolkit/docs/4.0/security/GT4-GSI-Overview.pdf.

[17] V. Welch, I. Foster, C. Kesselman, O. Mulmo, L. Pearl-man, S. Tuecke, J. Gawor, and S. M. andF. Siebenlist.,“X.509 proxy certificates for dynamic delegation,” inProc. of the 3rd Annual PKI R&D Workshop, 2004.

[18] I. Foster, C. Kesselman, J. M. Nick, and S. Tuecke,“The physiology of the Grid: An open grid ser-vices architecture for distributed systems integra-tion.” June 2002, http://www.globus.org/research/papers/ogsa.pdf.

[19] V. Casola, A. Mazzeo, N. Mazzocca, and V. Vittorini,“A security metric for public key infrastructures,” Jour-nal of Computer Security, vol. 15, no. 2, 2007.

[20] J. Luna, O. Manso, and M. Manel, “Ocsp forgrids: Comparing prevalidation versus caching,” in 7thIEEE/ACM International Conference on Grid Comput-ing, Barcelona, 2006.

[21] J. Luna, O. Manso and M. Manel, “Using Ogroand Certiver to improve OCSP validation for grids,”in Proc. of the 1st Grid and Pervasive Conference(GPC2006), 2006.

[22] V. Casola, J. Luna, O. Manso, N. Mazzocca, M. Manel,and M. Rak, “Interoperable grid PKIs among untrusteddomains: an architectural proposal,” in Proc. of the 2ndGrid and Pervasive Conference (GPC2007), 2007.

[23] CertiVeR, “Certificate revocation and validation ser-vice,” 2006, www.certiver.com/.

[24] OGRO, “The open grid ocsp client api,” 2006,globusgrid.certiver.com/info/ogro.

[25] V. Casola, A. Cuomo, M. Rak, U. Villano, Security andperformance trade-off in Perfcloud, in: To appear in theProc. of VHPC2010, 2010.

[26] Amazon Inc., Elastic Compute Cloud, http://aws.amazon.com/ec2 (Nov 2008).

[27] R. Jain, Art of Computer Systems Performance Analy-sis Techniques For Experimental Design MeasurementsSimulation And Modeling, Wiley Computer PublishingJohn Wiley & Sons, 1991.

Author BiographiesValentina Casola is currently an Assistant Professor atthe Computer and System Engineering Department of theUniversity of Naples Federico II, Italy. She received theMSc degree in Electronic Engineering from the Universityof of Napoles Federico II with honors, in 2001. She got aPh.D. in Computer Engineering from the Second Universityof Napoli in 2004. Her research activities include both the-oretical and experimental issues, in the areas of security ofinformation systems and policy based approach for securityevaluation and management, these activities are documentedby many publications, in national and international journalsand conference proceedings.

Antonio Cuomo is a Ph.D. student at the University ofSannio, Benevento, Italy. His research activities focuson performance evaluation and prediction of parallel anddistributed computer systems, including Cloud Computing,GRID Computing and their integration. He is currentlytaking part in an Italian project concerning the developmentof a volunteer-based cloud computing platform with anemphasis on performance management. He received thelaurea specialistica degree cum laude in Computer ScienceEngineering from the University of Sannio in 2009.

Massimiliano Rak is currently an Assistant Professor atthe Information Engineering Department of the SecondUniversity of Naples, Italy. He received the MSc degree inComputer Science Engineering from the University of ofNapoli Federico II in 1999. He got a Ph.D. in Computer En-gineering from the Second University of Napoli in 2002. Hisresearch activities include both theoretical and experimentalissues, in the areas of performance evaluation of computingsystems, parallel and distributed software engineering,security of information systems, and they are documentedby many publications, in national and international journalsand conference proceedings.

Umberto Villano is full professor at the University of Sannioat Benevento, Italy, where he is Director of the Departmentof Engineering. His major research interests concern per-formance prediction and analysis of parallel and distributedcomputer architectures, tools and environments for parallelprogramming and distributed algorithms. He received theLaurea degree in Electronic Engineering cum laude from theUniversity of Naples in 1983.

321Identity Federation in PerfCloud: an Architecture for Cloud and GRID Integration