An Overview of Cloud Identity Management-Modelspdfs.semanticscholar.org › fcb6 › 0e66a6e5935c0f5cf... · Keywords: Cloud, Cloud Computing, Cloud Identity Management-Model, Identity

An Overview of Cloud Identity Management-Models

Bernd Zwattendorfer, Thomas Zefferer and Klaus StranacherInstitute for Applied Information Processing and Communications (IAIK), Graz University of Technology,

Inffeldgasse 16a, 8010 Graz, Austriafbernd.zwattendorfer, thomas.zefferer, [email protected]

Keywords: Cloud, Cloud Computing, Cloud Identity Management-Model, Identity Management.

Abstract: Unique identification and secure authentication are essential processes in various areas of application, e.g.in e-Government, e-Health, or e-Business. During the past years several identity management-systems andmodels have evolved. Many organizations and enterprises or even countries for their national eID solutionsrely on identity management-systems for securing their applications. Since more and more applications aremigrated into the cloud, secure identification and authentication are also vital in the cloud domain. How-ever, cloud identity management-systems need to meet slightly different requirements than traditional identitymanagement-systems and thus cannot be clustered into the same model types or categories. Therefore, in thispaper we give an overview of different cloud identity management-models that have already emerged up tonow. We further compare these models based on selected criteria, e.g. on practicability and privacy aspects.

1 INTRODUCTION

Secure and reliable identity management (IdM) playsa vital role in several security-sensitive areas of ap-plications, e.g. in e-Government, e-Business, ore-Health. An identity management-system helpsonline applications to control access for users toprotected resources or services. However, identitymanagement is no new topic and several identitymanagement-approaches and systems have alreadyemerged over time. A comprehensive overview onidentity management-systems is given in (Bauer et al.,2005).

Due to the increasing number of cloud comput-ing adoption and the deployment of security-sensitivecloud applications, secure identity management be-comes also more and more important in the cloud do-main. In addition, outsourcing identity management-systems to the cloud can bring up several benefitssuch as higher scalability or cost savings, since noin-house infrastructure needs to be hosted and main-tained. However, the field of cloud identity manage-ment is still new and not extensively investigated yet.Therefore, the aim of this paper is to overview dif-ferent cloud identity management-models, discuss ad-vantages and disadvantages of the individual models,provide a comprehensive survey, and finally comparethem based on selected criteria. The criteria for thecomparison have been selected by focusing on practi-

cability and privacy, since one of the main issues ofcloud computing is the loss of data protection andprivacy (Pearson and Benameur, 2010), (Zissis andLekkas, 2012), and (Sen, 2013).

The paper is structured as follows. Section 2classifies existing traditional identity management-models and their implementations. Section 3 surveysexisting cloud identity management-models and de-scribes their benefits and drawbacks. These modelsare compared in Section 4 based on selected criteria.Finally, conclusions are drawn in Section 5.

2 TRADITIONAL IDENTITYMANAGEMENT-MODELS

An identity management-system usually involves fourentities (Bertino and Takahashi, 2011). A serviceprovider (SP) provides different online services tousers. Before being allowed to consume such ser-vices, a user has to successfully identify and authen-ticate. Therefore, the user usually identifies and au-thenticates at a so-called identity provider (IdP). Theidentity provider is then in charge of providing theusers identity data and supplementary authenticationresults to the service provider in a secure way. Fi-nally, a control party, which is usually a law or regula-tion enforcing body, needs to investigate identity datatransactions, e.g. for data protection reasons. Hence,

82

main purpose of such control party is auditing. Figure1 illustrates the communication process in an identitymanagement-system including all four entities.

Figure 1: Entities involved in an identity management-system.

Over time, several identity models involving thesefour entities and supporting similar but slightly dif-ferent use cases have evolved. Some of these mod-els have advantages in scalability, others in privacy oruser control. In the following subsections we brieflydescribe the most important models based on the workof (Cao and Yang, 2010), (Dabrowski and Pacyna,2008), (Dbrowski and Pacyna, 2008), (Jøsang et al.,2005), (Jøsang and Pope, 2005), (Jøsang et al., 2007),and (Palfrey and Gasser, 2007). For simplicity, weskip a discussion of the control party in all subsequentmodels because its functionality remains the same inall models.

2.1 Isolated Model

The isolated model is basically the simplest tradi-tional identity model. In this model, the serviceprovider and identity provider merge, hence identi-fication and authentication are directly carried out atthe service provider. In addition, the functionality ofthe identity management-system (creating, maintain-ing, or deleting identities) can only be used by thisspecific service provider. If a user wants to access ser-vices of another service provider, she needs to registerat the other service providers identity management-system again. This further means that each individualservice provider has to store and maintain the identitydata and credentials of the user separately. While thisstill may not be a huge burden for service providers,the diversity of credentials for accessing various ser-vice providers may become unmanageable for users(Jøsang and Pope, 2005). This model can still be

found by service providers on the Internet.

2.2 Central Model

The central identity model avoids diverse identitymanagement-systems, where the user has to registerseparately. Instead, the identity management-systemis outsourced by several service providers to a centralidentity provider. The identity provider takes over allidentity-related functionality for the service provider,including credential issuance, identification and au-thentication, and the management of the identity life-cycle in general (Bertino and Takahashi, 2011). Fur-thermore, in this model users’ identity data are storedin a central repository at the identity provider and ser-vice providers do not need to maintain identity datain their own repositories (Cao and Yang, 2010). Forauthentication at a service provider, the user has toidentify and authenticate at the identity provider be-fore. The identity provider then assembles a tokenincluding all necessary identity and authentication in-formation of the user and transmits it to the serviceprovider1. (Jøsang et al., 2005) further distinguish thedomain model for the identifier used. In the commonidentifier model one and the same identifier is usedfor identification at all service providers. In contrastto that, in the meta identifier domain model separateidentifiers are used for identification at the individ-ual service providers. However, all separate identi-fiers map to a common meta identifier at the identityprovider to uniquely identify the user. Typical exam-ples implementing this approach are Kerberos (Neu-man et al., 2005) or the Central Authentication Ser-vice (CAS)2.

2.3 User-centric Model

While in the central model all identity data of the userare stored in the domain of the identity provider, in theuser-centric model all identity data are stored directlyin the users domain, e.g. on a secure token such as asmart card. The main advantage of this model is thatthe user always remains the owner of her identity dataand stays under their full control (Dbrowski and Pa-cyna, 2008). Identity data can only be transferred byan identity provider to a service provider if the userexplicitly gives her consent to do so. Compared tothe central model, this tremendously increases users’privacy. (Jøsang and Pope, 2005) discuss in detailthis user-centric approach. Typical examples imple-

1Different approaches exist; hence identity data can beeither pushed to or pulled from the service provider.

2http://www.jasig.org/cas

An�Overview�of�Cloud�Identity�Management-Models

83

menting this model are Windows CardSpace3 or var-ious national eID solutions such as the Austrian cit-izen card (Leitold et al., 2002) or the German eID(Frommm and Hoepner, 2011).

2.4 Federated Model

In the federated model identity data are not stored ina central repository but are rather stored distributedacross different identity and/or service providers. Nosingle entity is fully controlling the identity informa-tion (Palfrey and Gasser, 2007). The distributed iden-tity data of a particular user are linked usually by thehelp of a common identifier4. All identity providersand service providers, which take part in such a fed-eration, share a common trust relationship amongsteach other. The trust relationship is usually estab-lished on organizational level whereas enforcement iscarried out on technical level. This federated modelparticularly supports identification and authenticationacross different domains, which paves the way forcross-domain single sign-on (Cao and Yang, 2010).Popular examples of this approach are the SecurityAssertion Markup Language (SAML)5, Shibboleth6,or WS-Federation (Kaler and McIntosh, 2009).

3 CLOUD IDENTITYMANAGEMENT-MODELS

Cloud computing is currently still one of the mostemerging trends in the IT sector. Many applicationsare already migrated to the cloud because of its ben-efits such as cost savings, scalability, or less main-tenance efforts (Armbrust et al., 2009). Due to theincreasing number of cloud applications, secure iden-tity management is equally important for cloud ap-plications as for traditional web applications. Hence,new cloud identity management-models have alreadyemerged, which particularly take the properties ofcloud computing into account. (Cloud Security Al-liance, 2011), (Cox, 2012), (Gopalakrishnan, 2009),(Goulding, 2010), or (Zwattendorfer et al., 2013) al-ready describe cloud identity management-models intheir publications. We take these publications as abasis to give an overview of different existing cloud

3http://msdn.microsoft.com/en-us/library/vstudio/ms733090%28vvs.90%29.aspx

4It is not necessary that the common identifier is shared.Different identifiers mapping to the same user are also pos-sible (Cao and Yang, 2010).

5http://saml.xml.org6http://shibboleth.net

identity management-models. In the following sub-sections we describe the individual models in moredetail and explain how and where identities are storedand managed.

3.1 Identity in the Cloud-Model

The Identity in the Cloud-Model is similar to the iso-lated identity model described in Section 2.1. Again,identity provider and service provider merge also inthis model. This means for the cloud case that thecloud service provider, which hosts the application, isalso responsible for the identity management. Figure2 illustrates this model.

Figure 2: Identity in the Cloud-Model.

Identity data of users, who are accessing the cloudapplication, are directly stored in the domain of thecloud service provider. Hence, the user has actu-ally no control which data are processed in the cloud.Cloud service providers which already use this modelfor their Software as a Service (SaaS) applicationsare for instance Google or Salesforce.com. They of-fer their own user management to their customers formanaging their own identities. The main advantageof this model is that organizations do not need to hostand maintain their own identity management-systembut can simply rely on an existing one, which will bemaintained by the cloud service provider. Needlessto say that costs can be decreased at an organizationwhen applying this model. However, the use of thismodel also shifts responsibility in terms of securityand privacy to the cloud service provider and the orga-nization more or less looses control over the identitydata stored and managed in the cloud.

WEBIST�2014�-�International�Conference�on�Web�Information�Systems�and�Technologies

84

3.2 Identity to the Cloud-Model

The Identity to the Cloud-Model is similar to the tra-ditional central identity model. Also in this model,the identity provider takes over the tasks regardingidentity management for the service provider. How-ever, the main difference in this model is that theservice provider and its applications are cloud-based.This further means that in this model the identityprovider is not deployed in the cloud, which avoidsunnecessary identity data disclosure to a cloud ser-vice provider. Figure 3 illustrates the Identity to theCloud-Model.

Figure 3: Identity to the Cloud-Model.

In more detail, the complete user and identitymanagement is still hosted by the organization e.g.in one of its data centers. Before gaining access toa cloud application, users have to authenticate at theidentity provider first. After that, the identity providertransfers appropriate identity and authentication datato the cloud service provider through well-defined andstandardized interfaces. Google or Salesforce.com,for instance, rely on SAML, OpenID7, or OAuth8 forthese interfaces and external identity provisioning.

Appliance of this model has the advantage that anexisting identity management-infrastructure of an or-ganization can be re-used. Users are identified andauthenticated at the cloud application by the use ofthis external identity management-system. No newuser management has to be created or migrated to thecloud service provider. The organization remains un-der control of the identity data and provides it to thecloud service provider just on demand. However, in-teroperability issues may arise due to the use of ex-ternal interfaces. For instance, a common agreement

7http://openid.net8http://oauth.net

on the attributes transferred (e.g. format or seman-tic) between the identity provider and the cloud ser-vice provider must be given. In addition, the identityprovider must support the interface provided by thecloud service provider.

3.3 Identity from the Cloud-Model

The Identity from the Cloud-Model fully features thecloud computing paradigm. In this case, both thecloud application and the identity provider are oper-ated in the cloud. However, in contrast to the Iden-tity in the Cloud-Model of Section 3.1 both enti-ties are operated by distinct cloud service providers.Since identities are provided as a service from thecloud, this model is also named ”Identity as a ServiceModel” (Ates et al., 2011). Google or Facebook arefor instance such providers, when using the authenti-cation functionality for other services than their own(Google Accounts Authentication and Authorization9

or Facebook Login10). Figure 4 illustrates this model.

Figure 4: Identity from the Cloud-Model.

By applying this model, an organization can ben-efit from the pure cloud computing advantages suchas high scalability or elasticity. Besides that, com-pared to the previous cloud identity management-models the advantage of this model is the separationof cloud service providers. In this model, organiza-tions can select their preferred identity provider in thecloud. This is particularly important because the or-ganization needs to trust the identity provider, whichis responsible for the organization’s identity and usermanagement. Organizations must be careful in cloudservice provider selection, as e.g. legal implicationssuch as data protection regulations might hinder theselection of a provider which stores identity data in aforeign country.

9https://developers.google.com/accounts10https://developers.facebook.com/docs/facebook-login


85

3.4 Cloud Identity Broker-Model

The Cloud Identity Broker-Model can be seen asan extension to the Identity from the Cloud-Model.In this Cloud Identity Broker-Model, the identityprovider in the cloud acts now as an identity brokerin the cloud. In other words, the cloud identity bro-ker is some kind of hub between one or more serviceproviders and one or more identity providers. Figure5 illustrates this model.

Figure 5: Cloud Identity Broker-Model.

The basic idea behind this model is to decouplethe service provider from integrating and connect-ing a vast amount of identity providers. If no bro-ker is used, a single service provider has to imple-ment all interfaces for communication with the indi-vidual identity providers if the service provider wantsto support them. By applying the broker concept, theidentity broker hides the complexity of the individ-ual identity providers from the service provider. Thisfurther means that the service provider just needs toimplement one interface, namely the one to the iden-tity broker. All other interfaces are encapsulated bythe identity broker and tailored or mapped to the ser-vice provider’s interface. In addition, for the ser-vice provider only one strong trust relationship be-tween the service provider and the identity broker isrequired. All other trust relationships with the indi-vidual identity providers are ”brokered” by the iden-tity broker. Deploying the broker in the cloud makesthis model even more powerful. Due to the cloudadvantages of nearly unlimited computing resourcesand scalability, a high number of active connectionsand identification/authentication processes at the bro-ker can be easily absorbed by the cloud.

Nevertheless, still some disadvantages can befound in this model. One disadvantage is that boththe user and the service provider are dependent onthe functionality the cloud identity broker supports. Ifthe identity broker does not support the desired iden-tity provider the user wants to use for authentication,the service provider cannot provide its services to theuser. Furthermore, if the broker does not support thecommunication interface to the service provider any-more, the service provider is cut off from any otheridentity provider. However, probably the main is-sue is that identity data runs through the cloud iden-tity broker in plaintext. As already mentioned before,privacy issues concerning the cloud service providermight hinder adoption of this cloud-based identitymanagement-service (Pearson and Benameur, 2010).

The Cloud Identity Broker-Model has alreadybeen implemented by some organizations. McAfeeCloud Single Sign On11, the SkIDentity12 implemen-tation, or the Cloud ID Broker13 of Fugen are justa few examples. Further details on this model canbe found in (Cloud Security Alliance, 2011), (Huanget al., 2010), or (Zwattendorfer et al., 2013).

3.5 Federated Cloud IdentityBroker-Model

The Federated Cloud Identity Broker-Model com-bines the traditional federated identity model with thenewly Cloud Identity Broker-Model. This combinedmodel has been introduced by (Zwattendorfer et al.,2013) and aims on eliminating the drawbacks of thecentral Cloud Identity Broker-Model. The general ar-chitecture is illustrated in Figure 6, showing the fed-eration of two different cloud identity brokers.

Compared to the simple Cloud Identity Broker-Model, in this federated model users and serviceproviders do not need to rely on one and the sameidentity broker. Actually, both the user and the ser-vice provider can rely on the individual broker of theirchoice. This eliminates the drawback for both theuser and the service provider of being dependent onthe same identity broker. On the one hand, users cansimply select the identity broker that supports all theirdesired identity providers (Identity Broker 1 in Figure6). On the other hand, service providers can select thebroker that e.g. supports a specific communicationinterface (Identity Broker 2 in Figure 6). Hence, re-ferring to Figure 6 the communication process flow

11http://www.mcafee.com/us/products/cloud-single-sign-on.aspx

12http://www.skidentity.com13http://fugensolutions.com/cloud-id-broker.html


86

Figure 6: Federated Cloud Identity Broker-Model.

between identity provider and service provider is bro-kered through the two Identity Brokers 1 and 2.

While this model eliminates some problems of theCloud Identity Broker-Model, the issue of plain iden-tity data transfer between and through cloud serviceproviders still persists. To bypass such privacy issue,the following two models had been introduced.

3.6 BlindIdM-Model

The BlindIdM-Model has been introduced by (Nunezet al., 2013) and (Nunez and Agudo, ress)14 and canalso be seen as an extension and alteration of the Iden-tity from the Cloud-Model. The basic idea is princi-pally the same, however, this model enables identitydata storage and data processing also by semi-trustedidentity providers15 in the cloud. In fact, the identityprovider in the cloud can provide identity data to ser-vice providers without actually knowing the contentsof these data. Hence, the identity provider providesthese data in a blind manner (Nunez et al., 2013). Thisparticularly preserves users’ privacy, as only blindeddata is transferred through the cloud identity providerand the cloud provider has no possibility to inspectthese data.

The identity data being transferred are actually

14a similar approach has been introduced by (Zwatten-dorfer and Slamanig, 2013a)

15A semi-trusted identity provider is an identity providerthat works correctly but may be interested in inspecting pri-vate data. In other words, the identity provider acts honestbut curious.

blinded by using a proxy re-encryption scheme16

(Green and Ateniese, 2007) (Ateniese et al., 2006).In more detail, during identity management setup anduser registration the organization stores the users’identity data in encrypted format at the cloud identityprovider. Thereby, the private key is kept confidentialby the organization, hence the cloud provider is notable to decrypt the stored identity data. In addition,the organization generates a re-encryption key for theidentity provider17, which allows the re-encryptionfrom the stored data encrypted for the cloud iden-tity provider into other encrypted data, which how-ever can be decrypted by the service provider. Duringan authentication process, the cloud identity providerthen just re-encrypts the desired identity data of theuser for the service provider. The practical applica-bility of the BlindIdM-Model has been shown by animplementation in connection with OpenID (Nunezet al., 2012).

3.7 Privacy-Preserving FederatedCloud Identity Broker-Model

The main aim of this model is – similar to theBlindIdM-Model – an improved privacy-preservationfor the user. Thereby, the same concept of ”blinding”

16By using proxy re-encryption a semi-trusted proxy canalter a ciphertext, which has been encrypted for person A,in such a way that it can be decrypted by person B. Thereby,the proxy gains no access to the plaintext of the data.

17For generating a re-encryption key, the organizationrequires its private key and the public key of the serviceprovider.


87

identity data is applied to the basic Federated CloudIdentity Broker-Model. Hence, this model com-bines the advantages of the Federated Cloud IdentityBroker-Model with the advantages of the BlindIdM-Model. Furthermore, this model can again be appliedwhen having semi-trusted cloud identity brokers. Thegeneral concept of this model has been introduced by(Zwattendorfer, 2014).

The general concept of this model is similar to theBlindIdM-Model because also proxy re-encryption isused for protecting identity data from the cloud ser-vice providers. However, the main differences arethat the data can also be stored encrypted at non-cloud identity providers and that the data can also beencrypted by the user and not only by an organiza-tion. In addition – which is the basic concept of thisfederated model – there are two re-encryption stepsrequired, since identity data needs to flow at leastthrough two cloud identity brokers. For instance, letsassume that the user has stored some identity data,which are encrypted for Identity Broker 1, at an iden-tity provider. To successfully run such a privacy-preserving authentication process, the user addition-ally has to generate two re-encryption keys (One forthe direction Identity Broker 1 ! Identity Broker 2and one for the direction Identity Broker 2 ! ser-vice provider) and issues them to the respective en-tities. Finally, after successful authentication at theidentity provider, identity data are transferred throughthe chain identity provider ! Identity Broker 1 !Identity Broker 2 ! service provider by applyingproxy re-encryption in the last two steps (The iden-tity data was already encrypted for Identity Broker1 during storage at the identity provider, hence onlytwo instead of three re-encryption steps are required).An application of this model can be found in (Zwat-tendorfer and Slamanig, 2013b), where parts of theSTORK18 framework are realized using this architec-ture to enhance scalability by ensuring users’ privacyat the same time.

4 COMPARISON OF CLOUDIDENTITYMANAGEMENT-MODELS

In this section we evaluate, discuss, and compare thevarious cloud identity management-models based ondifferent criteria. Comparison criteria are defined inthe following Subsection 4.1 whereas the comparisonitself is elaborated in Subsection 4.2.

18Secure Identity Across Borders Linked,https://www.eid-stork.eu/

4.1 Comparison Criteria

The following criteria act as a basis for comparing thevarious cloud identity management-models. Some ofthe comparison criteria were selected or derived from(Cao and Yang, 2010), (Nunez et al., 2013), and (Bir-rell and Schneider, 2013). The selected criteria tar-get aspects of different areas (e.g. general architec-ture, trust, privacy, etc.). The diversity of the criteriawas deliberately considered to give a comprehensiveoverview on the different cloud identity management-models.

Number of SPs Supported: Is the model limited toone SP or can multiple SPs be supported?

Number of IdPs Supported: Is the model limited toone IdP or can multiple IdPs be supported?

Trust Domains: Is authentication supported onlywithin a single trust domain or also across differ-ent trust domains?

Trust Model: Is a direct trust model or a brokeredtrust model applied?

Trust in the Cloud IdP/identity Broker: Must thecloud identity provider/identity broker be trustedor can they be semi-trusted?

Single sign-on (SSO): Can the model support singlesign-on (SSO)?

Storage Location of Identity Data: Where areusers’ identity data stored?

Scalability: Is the model applicable in a large scale?

Extensibility: Is the model easily extensible, e.g. byadding new service providers?

Governance Framework: Is a governance frame-work involving several entities required?

Cost Effectiveness: Is the model cost effective?

Confidentiality: Does the identity data stay confi-dential at the identity provider/identity broker?

Minimal/Selective Disclosure: Can the user selectthe amount of identity data to be disclosed to theidentity provider/service provider?

User Control: Does the user have full control overher identity data?

Unlinkability: Is the user unlinkable to the identityprovider/identity broker? In other words, are dif-ferent authentication processes of the same userlinkable?

Anonymity: Can the user stay anonymous with re-spect to the identity provider/identity broker?


88

4.2 Comparison

In this section we compare the individual cloud iden-tity management-models with respect to the priordefined criteria. Table 1 shows and summarizesthis comparison. For some comparisons we usequalitative arguments, for others quantitative argu-ments (low, medium, high), and for the rest simplyboolean (e.g. yes/no for being applicable or not) ar-guments. The options marked in bolt indicate the re-spective best option (only applicable for quantitativeand boolean values). The underlying principle for allcomparisons (in particular for those that are related toprivacy such as confidentiality, minimal/selective dis-closure, etc.) is that we assume an identity provider oran identity broker deployed in the cloud acting hon-est but curious (thus being semi-trusted). In contrastto that we assume applications in the cloud and theirhosting service providers as being trusted, as theyanyhow require users’ identity data for service pro-visioning.

In the following we discuss the various modelsbased on the individual criteria.

Number of SPs Supported: Since in the Identity inthe Cloud-Model the service provider and theidentity provider are the same entity, the identityprovider can only serve one service provider. Allother models have no such restriction and thus canprovide multiple service providers with identitydata.

Number of IdPs Supported: Only those modelsthat rely on a broker-based approach are able todeal with multiple connected identity providers.All others just include one identity provider.Dealing with multiple identity providers hasthe advantage that a user can simply select herpreferred identity provider for an authenticationprocess. Different identity providers can havedifferent identity data stored or support differentqualities in the authentication mechanisms.This allows users to select the identity providersatisfying best the needs for authentication at aservice provider.

Trust Domains: The broker-based models supportauthentication across multiple trust domains, asmultiple entities are involved during an authenti-cation process. All others support authenticationin single domains only.

Trust Model: Again, all models which rely on anidentity broker also feature a brokered trustmodel, hence the trust relationships are seg-mented. All other models rely on a direct orpairwise trust model, as only the service provider

and the identity provider communicate with eachother during an authentication process. A clearstatement which model has more advantages can-not be made. Both have their benefits and draw-backs, however, details on the individual modelscan be found in (Linn et al., 2004).

Trust in the Cloud IdP/identity Broker: For thetwo models (BlindIdM-Model and Privacy-Preserving Federated Cloud Identity Broker-Model), which rely on proxy re-encryption forsecuring the data during cloud transmission, it issufficient when the identity provider/identity bro-ker is considered semi-trusted. In all other cloudidentity models the identity provider/identitybroker must be trusted.

Single sign-on (SSO): In fact, all models that canhandle multiple service providers are principallyapplicable to support single sign-on. This means,that only the Identity in the Cloud-Model cannotsupport a simplified log-in process.

Storage Location of Identity Data: In the Identityto the Cloud-Model identity data are stored ona single external identity provider, which is ca-pable of providing identity to the cloud ap-plication through a well-defined interface. Inthe broker-based models, identity data can bestored distributed across multiple different iden-tity providers, being either deployed in the cloudor in a conventional data center. However, the dif-ferent identity providers could also have identitydata stored redundantly, i.e. the same attributename/value-pair is stored at different providers.No identity data are actually stored at the iden-tity broker. In the remaining cloud identity mod-els identity data are stored directly at the cloudidentity provider.

Scalability: The Identity to the Cloud-Model has thelowest scalability, as an external identity provideris usually not designed for dealing with highload activities. In addition, an external iden-tity provider has not that flexibility or elasticitythat an identity provider deployed in a cloud has.Hence, such cloud identity providers (Identity inthe Cloud-Model, Identity from the Cloud-Model,and BlindIdM-Model) have higher scalability fea-tures. Although in these three models the iden-tity provider/identity broker is deployed in thecloud, we rated the models with just medium levelscalability. The reason is that with the broker-based models load can additionally be distributedto other identity providers and thus is not bundledat one single provider. Hence, the broker-basedmodels achieve the highest scalability.


89

Table 1: Comparison of the individual cloud identity management-models based on selected criteria.

Criterion /Model

Identity in theCloud-Model

Identity to theCloud-Model

Identity fromthe Cloud-Model

Cloud Iden-tity Broker-Model

FederatedCloud Iden-tity Broker-Model

BlindIdM-Model

Privacy-PreservingFederatedCloud Iden-tity Broker-Model

Number of SPssupported

One Multiple Multiple Multiple Multiple Multiple Multiple

Number ofIdPs supported

One One One Multiple Multiple One Multiple

Trust domains One One One Multiple Multiple One MultipleTrust model Direct Direct Direct Brokered Brokered Direct BrokeredTrust inthe cloudIdP/identitybroker

Trusted Trusted Trusted Trusted Trusted Semi-Trusted Semi-Trusted

Single sign-on(SSO)

No Yes Yes Yes Yes Yes Yes

Storage loca-tion of identitydata

Cloud identityprovider

External iden-tity provider


Cloud iden-tity providerand exter-nal identityprovider




Scalability Medium Low Medium High High Medium HighExtensibility Low Medium Medium High High Medium HighGovernanceframework

No No No Yes Yes Yes Yes

Cost effective-ness

Medium Medium Medium High High Medium High

Confidentiality No No No No No Yes YesMinimum/Selectivedisclosure

No Yes No Yes Yes No Yes

User Control No Yes No Yes Yes No YesUnlinkability No No No No No No YesAnonymity No No No No No Yes Yes

Extensibility: The Identity in the Cloud-Model can-not be extended because service provider andidentity provider are one and the same entity. TheIdentity to the Cloud-Model, the Identity from theCloud-Model, and the BlindIdM-Model can be ex-tended to integrate additional service providers.Nevertheless, the broker-based models have thebest extensibility as from their nature the generalaim is to support multiple service providers andidentity providers.

Governance Framework: The non-broker-basedcloud identity models do not require an extensivegovernance framework as only a simple pairwise(direct) trust model applies. In the broker-basedconcepts a thorough governance framework is re-quired as multiple providers have to interact. Forthe privacy-preserving models (BlindIdM-Modeland Privacy-Preserving Federated Cloud IdentityBroker-Model) the governance framework getseven more complex, as encryption keys have to

be managed for the individual entities.

Cost Effectiveness: The broker-based models havethe highest cost effectiveness, since the identitybrokers are deployed in the cloud and addition-ally multiple identity providers can be connectedand re-used. Due to the re-use of existing externalidentity providers, costs can be saved. The samearguments also hold for the Identity to the Cloud-Model, where an existing identity management-system through an external interface is re-used foridentity data provisioning. However, this modelcannot benefit from the advantages of an identityprovider in the cloud deployment, which leads tomedium cost effectiveness only. All other modelsalso have medium cost effectiveness, as the iden-tity provider is deployed in the cloud but no exist-ing identity providers can be re-used.

Confidentiality: Only the BlindIdM-Model and thePrivacy-Preserving Federated Cloud IdentityBroker-Model support confidentiality with respect


90

to the cloud service provider because the iden-tity data transferred through the cloud serviceprovider are encrypted. In comparison, in all othercloud identity models identity data are routed inplaintext through the cloud service provider thathosts the cloud identity provider/identity broker.

Minimum/Selective Disclosure: For evaluating thiscriterion we assume that minimum/selective dis-closure is only possible at trusted identityproviders. Hence, this feature is only supportedwhere external (and trusted) identity providers arepart of the model. These are the broker-basedmodels as well as the Identity to the Cloud-Model.All other models rely on cloud identity providersonly.

User Control: Again, for evaluating this criterion weassume that full user-control is only possible attrusted identity providers. Therefore, the same re-sults as for the comparison with respect to mini-mum/selective disclosure apply.

Unlinkability: The user – in fact – is only un-linkable with respect to the identity broker inthe Privacy-Preserving Federated Cloud IdentityBroker-Model. The reasons are that, on the onehand, the identity broker just sees encrypted dataand, on the other hand, that the encrypted datacan be randomized if certain proxy re-encryptionschemes such as from (Ateniese et al., 2006) areused. The randomization feature allows to pro-vide the identity broker with different ciphertextsduring different authentication processes althoughthe containing plaintext data remains the same.Hence, this avoids user linkage during differentauthentication processes of the same user. Al-though the BlindIdm-Model supports proxy re-encryption too, the randomization feature has noeffect in this case because the encrypted data aredirectly stored at the cloud identity provider. If theuser wants to update her encrypted identity data atthe cloud identity provider, she must somehow belinkable. All other models also do not support un-linkability because identity data flows through theidentity provider/identity broker in plaintext.

Anonymity: The only two models that supportanonymity with respect to the identity broker arethe BlindIdM-Model and the Privacy-PreservingFederated Cloud Identity Broker-Model. In thesetwo models the identity data are fully hidden fromthe identity broker due to encryption. Even ifthe user is linkable, the broker cannot reveal theuser’s identity. In all other models anonymity withrespect to the identity provider/identity broker isnot possible because identity data are processed

in plaintext.

5 CONCLUSIONS

Based on the comparison and discussion of the differ-ent cloud identity management-models it can be con-cluded that the Privacy-Preserving Federated CloudIdentity Broker-Model does the best with respect tothe selected criteria. It supports the main basic func-tions like all other cloud identity models but addition-ally tremendously increases users’ privacy. However,application of this model is also more complex thanthe others. Reasons are the support of authenticationacross several domains of multiple identity providersand service providers and the incorporation of pri-vacy features due to the use of proxy re-encryption.Furthermore, the use of proxy re-encryption requiresa thorough key management, which implies the ne-cessity of an appropriate governance framework. Inaddition, the brokered trust model might be a block-ing issue for further adoption of this model as liabil-ity is shifted to the intermediary components (iden-tity brokers). However, in general the broker-basedcloud identity management-models have more advan-tages than the simple cloud identity management-models. Nevertheless, the use of any cloud identitymanagement-model is advantageous compared to tra-ditional identity management-models as they providehigher scalability and better cost effectiveness due tothe cloud computing features.

REFERENCES

Armbrust, M., Fox, A., Griffith, R., Joseph, A. D., Katz,R., Konwinski, A., Lee, G., Patterson, D., Rabkin, A.,Stoica, I., and Zaharia, M. (2009). Above the Clouds: A Berkeley View of Cloud Computing Cloud Com-puting. Technical report, RAD Lab.

Ateniese, G., Fu, K., Green, M., and Hohenberger, S.(2006). Improved proxy re-encryption schemes withapplications to secure distributed storage. ACM Trans.Inf. Syst. Secur., 9(1):1–30.

Ates, M., Ravet, S., Ahmat, A. M., and Fayolle, J. (2011).An Identity-Centric Internet: Identity in the Cloud,Identity as a Service and Other Delights. ARES 2011,pages 555–560.

Bauer, M., Meints, M., and Hansen, M. (2005). D3.1:Structured Overview on Prototypes and Concepts ofIdentity Management System. FIDIS.

Bertino, E. and Takahashi, K. (2011). Identity Management:Concepts, Technologies, and Systems. Artech House.

Birrell, E. and Schneider, F. (2013). Federated IdentityManagement Systems: A Privacy-based Characteriza-tion. IEEE Security and Privacy, 11(5):36–48.


91

Cao, Y. and Yang, L. (2010). A survey of Identity Manage-ment technology. In IEEE ICITIS 2010, pages 287–293. IEEE.

Cloud Security Alliance (2011). Security Guidance for Crit-ical Areas of Focus in Cloud Computing V3.0. CSA.

Cox, P. (2012). How to Manage Identity in the PublicCloud. InformationWeek reports.

Dabrowski, M. and Pacyna, P. (2008). Generic and Com-plete Three-Level Identity Management Model. InSECURWARE 2008, pages 232–237. IEEE.

Dbrowski, M. and Pacyna, P. (2008). Overview of Iden-tity Management. Technical report, chinacommunica-tions.cn.

Frommm, J. and Hoepner, P. (2011). The New GermaneID Card. In Fumy, W. and Paeschke, M., editors,Handbook of eID Security - Concepts, Practical Expe-riences, Technologies, pages 154–166. Publicis Pub-lishing, Erlangen.

Gopalakrishnan, A. (2009). Cloud Computing IdentityManagement. SETLabs Briefings, 7(7):45–55.

Goulding, J. T. (2010). identity and Access Managementfor the Cloud : CAs Strategy and vision. TechnicalReport May, CA Technologies.

Green, M. and Ateniese, G. (2007). Identity-Based ProxyRe-encryption. In ACNS 2007, volume 4521 of LNCS,pages 288–306. Springer.

Huang, H. Y., Wang, B., Liu, X. X., and Xu, J. M. (2010).Identity Federation Broker for Service Cloud. ICSS2010, pages 115–120.

Jøsang, A., Fabre, J., Hay, B., Dalziel, J., and Pope, S.(2005). Trust Requirements in Identity Management.Proceedings of the 2005 Australasian workshop onGrid computing and e-research, pages 99–108.

Jøsang, A. and Pope, S. (2005). User Centric Identity Man-agement. AusCERT 2005.

Jøsang, A., Zomai, M. A., and Suriadi, S. (2007). Usabilityand privacy in identity management architectures. InACSW ’07, pages 143–152.

Kaler, C. and McIntosh, M. (2009). Web Services Federa-tion Language (WS-Federation) Version 1.2. OASISStandard.

Leitold, H., Hollosi, A., and Posch, R. (2002). Securityarchitecture of the Austrian citizen card concept. InACSAC 2002, pages 391–400.

Linn, J., Boeyen, S., Ellison, G., Karhuluoma, N., Mac-gregor, W., Madsen, P., Sengodan, S., Shinkar, S., andThompson, P. (2004). Trust Models Guidelines. Tech-nical report, OASIS.

Neuman, C., Yu, T., Hartman, S., and Raeburn, K. (2005).The Kerberos Network Authentication Service (V5).RFC 4120 (Proposed Standard).

Nunez, D., Agudo, I., and Lopez, J. (2013). LeveragingPrivacy in Identity Management as a Service throughProxy Re-Encryption. In Zimmermann, W., editor,Proceedings of the PhD Symposium at the 2nd Eu-ropean Conference on Service-Oriented and CloudComputing, pages 42–47.

Nunez, D. and Agudo, I. (In Press). Blindidm: A privacy-preserving approach for identity management as a ser-vice. International Journal of Information Security.

Nunez, D., Agudo, I., and Lopez, J. (2012). IntegratingOpenID with Proxy Re-Encryption to enhance privacyin cloud-based identity services. In IEEE CloudCom2012, pages 241 – 248.

Palfrey, J. and Gasser, U. (2007). CASE STUDY: DigitalIdentity Interoperability and eInnovation. BerkmanPublication Series,.

Pearson, S. and Benameur, A. (2010). Privacy, Securityand Trust Issues Arising from Cloud Computing. InCloudCom 2010, pages 693–702. IEEE.

Sen, J. (2013). Security and Privacy Issues in Cloud Com-puting. In Martınez, A. R., Marin-Lopez, R., andPereniguez-Garcia, F., editors, Architectures and Pro-tocols for Secure Information Technology Infrastruc-tures, pages 1–45. IGI Global.

Zissis, D. and Lekkas, D. (2012). Addressing cloud com-puting security issues. Future Generation ComputerSystems, 28(3):583–592.

Zwattendorfer, B. (2014). Towards a Privacy-PreservingFederated Identity as a Service Model. to appear.

Zwattendorfer, B. and Slamanig, D. (2013a). On Privacy-Preserving Ways to Porting the Austrian eID Systemto the Public Cloud. In SEC 2013, AICT, pages 300–314. Springer.

Zwattendorfer, B. and Slamanig, D. (2013b). Privacy-Preserving Realization of the STORK Framework inthe Public Cloud. In SECRYPT 2013, pages 419–426.

Zwattendorfer, B., Stranacher, K., and Tauber, A. (2013).Towards a Federated Identity as a Service Model. InEgovis 2013, pages 43–57.


92

Documents

An Overview of Cloud Identity Management-Modelspdfs.semanticscholar.org › fcb6 › 0e66a6e5935c0f5cf... · Keywords: Cloud, Cloud Computing, Cloud Identity Management-Model, Identity