The Intersection of Identity Management and Cloud Computing

The Intersection
of Identity Management
and Cloud Computing
© 2011 Hitachi ID Systems, Inc. All rights reserved.

Contents
1 Introduction 1
2 Background: Cloud Computing and IAM 2
2.1 The term “cloud” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Overview of cloud computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2.1 SaaS, PaaS, IaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2.2 Private, community, public and hybrid clouds . . . . . . . . . . . . . . . . . . . . . 2
2.2.3 Cloud vendors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.4 Examples of public cloud vendors . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Overview of identity and access management . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3.1 Identity administration vs. runtime access control . . . . . . . . . . . . . . . . . . . 4
2.3.2 Identity administration services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3.3 Access control services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Beneﬁts of Cloud Computing 6
3.1 Lower, predictable costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Capital vs. operating cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Expertly managed systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4 On-demand availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5 Faster provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4 Drawbacks of Cloud Computing 8
4.1 Control and dependence on third parties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Privacy and security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 Regulatory compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4 Flexibility and customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5 Reliability and connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.6 CSP business viability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.7 Service level agreements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5 Network Architecture of Cloud Computing 11
6 The Intersection of Cloud Computing and IAM 13
i

The Intersection of Identity Management and Cloud Computing
6.1 Identity as a service (IDaaS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2 Scenario analysis: identity administration and cloud computing . . . . . . . . . . . . . . . . 13
7 Summary 15
APPENDICES 16
A Scenario Analysis: Identity Administration and Cloud Computing 17
B Scenario Analysis: Privileged Password Management 49
B.1 Backup vault in the cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
B.2 Securing administrative access to cloud infrastructure . . . . . . . . . . . . . . . . . . . . . . 49
© 2011 Hitachi ID Systems, Inc. All rights reserved.

1 Introduction
This document is a comprehensive analysis of all the ways that Identity and Access Management (IAM)
solutions can be run in and integrate with cloud computing systems.
Both cloud computing and IAM are relatively new, so the first part of this document defines key concepts
and terminology. Next, assumptions that clarify the scope of this document in terms of network topology
and functionality are presented and finally a comprehensive list of architectural scenarios are presented,
along with an analysis of the costs, risks and benefits of each scenario.
© 2011 Hitachi ID Systems, Inc. All rights reserved. 1

2 Background: Cloud Computing and IAM
2.1 The term “cloud”
The term “cloud” is a metaphor for the Internet and originates with the cloud icons used to represent the
telephone system and the Internet in early network architecture diagrams. The cloud is an abstraction of
the underlying infrastructure of a network – usually the Internet.
The idea is essentially one of ambiguity – there are some services “out there,” “in the cloud” which can
be accessed over “some sort of network.” The amorphous shape of a cloud makes it clear that there is
ambiguity around the location of services and the connectivity to those services.
Cloud infrastructure is that of the typical data center, consisting of servers and network equipment. Services
offered in a cloud can range from simple application web user interfaces to dynamically allocated virtual
machines and databases. The key concept in cloud computing is to commoditize the infrastructure on
which an application runs, so that network connectivity, computing capacity, operating systems and more
are provisioned on demand, through a utility business model.1
2.2 Overview of cloud computing
2.2.1 SaaS, PaaS, IaaS
There are broadly three kinds of services offered by cloud vendors:
1. Cloud application services or Software as a Service (SaaS) delivers application software over the
Internet. This frees customers from having to provision hardware to host their own copies of these
applications, from installing the applications and from maintaining them.
2. Cloud platform services or Platform as a Service (PaaS) delivers application development and
runtime platforms as a service. These may include programming languages, runtime abstractions,
database services and more.
3. Cloud infrastructure services or Infrastructure as a Service (IaaS) delivers more complex computing
infrastructure, on demand. In this scenario, customers can provision not only individual virtual or
physical machines, but also the network topology that connects them as needed.
2.2.2 Private, community, public and hybrid clouds
There are a variety of implementations of the cloud concept:
1. A public cloud (or external cloud) is the most common. In this model, an cloud vendor offers solutions
that are dynamically provisioned on a ﬁne-grained, self-service basis, accessible over the Internet.
Usually the services are billed using a ﬁne-grained utility computing model.
1The term utility is used here in the sense of an electricity grid or telephone service provider.

2. A community cloud might be established when several organizations have similar computing re-
quirements and they wish to share infrastructure costs in order to realize some of the benefits of cloud
computing. This approach may offer a higher level of privacy, security or policy compliance than a
public cloud. An example of this approach is the Google “Gov Cloud”.
3. A private cloud typically refers to a set of servers that run virtual machines inside an organization’s
perimeter, where virtual servers can be activated and deactivated on demand. This allows organiza-
tions to get some of the benefits of cloud computing (i.e., rapid provisioning and deprovisioning) but
without relying on a third party. This eliminates both benefits and risks associated with a public cloud.
4. A hybrid cloud is an architecture that combines a private cloud with a public cloud. For example, an
application might be configured to normally run on a private cloud, except in situations where there
is short-lived high demand, in which case additional resources on a public cloud are also consumed.
Alternately, some components of an application might run on a public cloud while others remain inside
the corporate network perimeter.
2.2.3 Cloud vendors
Typically a cloud service provider (CSP) (or application service provider, cloud computing provider, or cloud
vendor) delivers common business applications via a network. These applications are accessed either by
other applications as web services or by users via their web browser. Application software and data reside
on servers managed by the CSP. In other words, a CSP is a business that provides computing capacity,
applications or data to customers over a network.
2.2.4 Examples of public cloud vendors
Following are some example CSPs, which illustrate the breadth of the cloud computing market:
Company PaaS offerings SaaS offerings
Microsoft Windows Azure Content Delivery
Network and Azure AppFabric
Exchange Online, Office Live,
SharePoint Online
Salesforce.com Force.com Sales cloud, Service Cloud, Chatter
ADP n/a Payroll, HR, Time/attendance,
procurement, many others.
Amazon Elastic Compute Cloud (EC2) Simple Pay, WebStore, etc.
Google App Engine, Gov Cloud Mail, Applications
Rackspace cloudservers, cloudfiles, cloudsites n/a
Hosting.com Cloud VPS, Cloud Enterprise, Cloud
Dedicated, Cloud Private
n/a
2.3 Overview of identity and access management

2.3.1 Identity administration vs. runtime access control
The term “identity and access management” is quite broad and can be used in reference to a wide variety
of services. IAM may refer to services designed to manage the definition of users, including their identity
attributes and security entitlements. Alternately, IAM can refer to services designed to intercept attempts
by users to access applications or data and to implement runtime security, including authentication, autho-
rization and audit.
In other words, there are administrative IAM services and runtime access control services. These two types
of services typically interact through a directory – managed by the former and consumed by the latter to
make runtime decisions.
2.3.2 Identity administration services
Administrative IAM systems manage the login accounts, security entitlements, identity attributes and au-
thentication factors assigned to users.
1. Password management is the ability of an IAM system to manage user passwords on one or more
systems or applications. Functionally, this includes password synchronization, self-service password
reset or the management of other authentication factors such as security questions or PINs on smart
cards and OTP tokens.
2. User provisioning is the ability of an IAM system to create, modify and delete login accounts for
users on systems and applications. This may be done as a consequence of a variety of business
processes, including auto-provisioning and deactivation driven by a data feed from an authoritative
system of record (SoR), delegated administration of users and entitlements by application owners,
managers or other non-IT staff, self-service requests for security entitlements or profile updates, ap-
provals workflow, periodic review of security entitlements and more.
3. Role Based Access Control (RBAC) is a strategy for user provisioning where sets of entitlements
are collected into roles and roles are assigned to users. This reduces the need to assign individual
entitlements to users, which is advantageous since individual entitlements are often very technical
and hard for business users to understand. Instead, roles with business-friendly names are assigned
to users, either by request or using rules expressed in terms of identity attributes.
4. Privileged access management (also known as privileged password management and privileged ID
management) is used to secure the access of users to accounts that have elevated security rights,
such as root on Unix, Administrator on Windows, etc. This is typically done by periodically changing
the passwords of these accounts to random values, storing those password values in a secure vault,
applying policy and workflow to control which user is allowed to connect to which account and injecting
passwords from the vault into login sessions.
2.3.3 Access control services
Another class of IAM functions is intended to secure the access of users to applications and data at runtime.
Access control systems authenticate users into applications and make real-time decisions about what a user
can and cannot do:

1. Web access management / web single signon (WebAM) authenticates users, tracks authentication
state (normally using cookies) and eliminates the need for users to sign into each application sepa-
rately. In some deployments, WebAM systems also enforce authorization rules, typically at the gran-
ularity of URLs. Users may still have login accounts and other data, such as preferences and ACLs,
on each application they sign into.
2. Federation allows users to authenticate in one domain and seamlessly access applications in another
domain. For example, a user might sign into a corporate Active Directory and use a federation system
to access a SaaS CRM application without having to manually sign into the SaaS application. Where
federation is used, the application users sign into may not have a persistent records of users (i.e., no
login IDs, preferences, etc.). Instead, applications can to trust the federation infrastructure to make
assertions about who legitimate users are and what they can access.
3. Claims based authentication and authorization systems are a form of federation, where assertions
about the identity, authentication status and authorization of users may be made by multiple providers.
For example, one system may make a claim about the user’s name, another about the user’s employer,
another about the user’s department, etc. The user’s web browser may combine these claims when
signing into an application, which then decides what access rights to grant the user based on the set
of assertions the user’s web browser can offer.

3 Benefits of Cloud Computing
3.1 Lower, predictable costs
Customers of cloud hosted applications generally hope to reduce costs as compared to deploying and main-
taining an equivalent application in-house, because “in-sourcing” applications requires expensive overhead
including IT staff salaries and benefits, physical space, power, cooling, hardware, operating system and
database licenses, etc.
Whether a cloud computing approach is actually cheaper than traditional purchase and deployment of
software depends on many variables – the fees charged by the cloud provider, the efficiency of the internal
IT organization and infrastructure, the life of the system, the number of upgrades required, etc. Ultimately,
cloud providers can offer lower cost only if they operate a very efficient infrastructure and take only modest
margins.
Cloud computing does offer one certain advantage, which is that application costs are predictable. With in-
sourced projects, surprises regarding hardware sizing, deployment effort and ongoing maintenance often
mean that total project cost is very different than initially predicted.
3.2 Capital vs. operating cost
The cost model that cloud providers offer their customers is essentially a lease – with flat monthly usage
fees, little or no up-front costs and no ownership. This compares to the traditional in-sourcing model, which
is essentially a purchase, with both a capital expense up front and ongoing operating expenses. This means
that one of the advantages of cloud computing for some organizations is a different tax treatment of their IT
expenses (OpEx vs. CapEx).
3.3 Expertly managed systems
An implicit assumption in cloud computing is that the CSP employs experts to manage their applications
and/or infrastructure. This often compares favorably with in-sourced applications, where organizations may
have trouble hiring and retaining appropriate and adequate expertise to efficiently and reliably manage their
systems.
3.4 On-demand availability
An advantage offered by most CSPs is on-demand availability. For example, virtual servers may be activated
and paid for by the month, by the day or even by the CPU-second. This is very attractive in cases where
organizations need capacity for just a short time.

3.5 Faster provisioning
In many organizations, it can take weeks or even months to provision new servers. It almost always takes
months to provision new applications. In contrast, an appealing characteristic of CSPs is that they can
provision virtual servers and provide access to new applications in just minutes.

4 Drawbacks of Cloud Computing
4.1 Control and dependence on third parties
At the heart of most objections to cloud computing is a concern about handing control over applications and
data to a third party. This basic concern may lead to a variety of objections, as described in the following
sections.
4.2 Privacy and security
All organizations are responsible for protecting the privacy of their employees and customers. Failure to pro-
tect private information has serious consequences including legal liability, ﬁnes and damage to reputation.
Moving applications and data to a 3rd party introduces a level of complexity to this responsibility:
1. Cloud service providers (CSPs) must take care to safeguard the security of data and applications on
their infrastructure.
2. Customers must select CSPs with robust security practices and may be obliged to validate the effec-
tiveness of those practices.
The cloud model has been criticized by privacy advocates because of the potential for privacy compromise
– of data in transit between customers and CSPs and on infrastructure that is shared among multiple CSP
customers.
To mitigate these concerns, CSPs must create secure applications, operate secure infrastructure and be
very transparent about the measures they take to achieve these goals. CSPs may also have to collect
detailed audit data about user access to applications and data and protect this audit trail, in the event that
a forensic audit is required.
Identity and access management (IAM) is relevant to this requirement, as robust processes are needed to
ensure that user access to CSP systems and applications is reliably authenticated, authorized and audited.
4.3 Regulatory compliance
A variety of regulations include strong and in some cases speciﬁc requirements for effective internal controls
and IT security. These include FISMA, HIPAA and SOX in the US, the Data Protection Directive in the EU
and the payment card industry data security standard (PCI-DSS).
These regulations can be complex to satisfy with a conventional IT infrastructure and only become more
so when applications are moved out of the corporate perimeter to 3rd party sites. For example, internal
controls processes must be mapped to contractual obligations which CSPs are obliged to meet.
Some regulations specify the legal jurisdiction where personally identifying information (PII) data may (and
may not) reside. For example, PII relating to EU citizens cannot be moved outside of the Eurozone, with
a few exceptions where the destination country has a compatible legal framework and possibly bilateral

agreements with EU member states. Another jurisdictional challenge is the bizarre and often mutually-
contradictory regulations some countries (e.g., USA, France, China) impose on companies doing business
in their countries, regarding the use and export of cryptographic technology.
Jurisdictional restrictions create challenges when organizations seek to move applications to global CSPs,
where the physical location of data cannot be predicted in advance or guaranteed over time. Regulations
regarding the use of cryptography make it more difﬁcult to meet regulations regarding PII.
In general, CSPs strive to address these concerns through a combination of sound security practices,
transparency and third party security audits.
4.4 Flexibility and customization
CSPs that cater to large numbers of customers have a strong economic incentive to standardize their
services, so that software development and operational costs can be divided over as many customers as
possible. Standardization allows CSPs to lower their internal costs, lower their prices and increase market
share.
Organizations that seek customized solutions may not be well served by CSPs with standardized and
possibly rigid offerings. In the SaaS case, they may be unable to effectively brand application UIs or to
adjust business processes to meet their needs. In the PaaS case, the development language or runtime
environment may be proprietary or limiting.
4.5 Reliability and connectivity
The reliability of cloud-hosted services depends on the ability of both end users and other corporate ap-
plications to communicate with those services. It also depends on the availability of those services where
they reside.
To meet these requirements, CSPs must operate robust data centers, load balance across different sites
and provide redundant, high speed connections between each site and the Internet. These requirements
add cost to CSP operations and therefore to service pricing.
In addition, customers must provide their own redundancy, in the form of multiple, high-speed Internet
connections. This also adds to the customer’s total cost of operation (TCO) for cloud-hosted services.
4.6 CSP business viability
When customers move mission-critical applications to a CSP, they are implicitly betting that the CSP will stay
in business and will continue to offer the service in question. Neither of these assumptions is necessarily
correct:
1. Some web hosting companies have abruptly closed their doors, causing both interruption to customer
services and loss of customer data.

2. Even CSPs that remain viable businesses may discontinue speciﬁc services, forcing customers to
migrate to new providers.
To mitigate these concerns, customers may require third party data escrow, guarantees of continued service
so long as the CSP is solvent and use of relatively standardized offerings, which can more easily be migrated
to replacement CSPs. All of these measures add cost.
4.7 Service level agreements
When moving a service from an internal deployment to a CSP, it is reasonable to specify the performance
of the service. This is done using a service level agreement (SLA) which may need to specify:
• Computational capacity, network capacity and storage allocated to the service.
• Responsiveness of the user interface.
• Throughput of any batch processing.
• Processes and technologies used to authenticate users, authorize their requests for service and audit
their actions.
• Security measures taken to protect the service and backing infrastructure against attack.
• Availability metrics, such as permissible downtime per year.
• Segregation between services provisioned to different CSP customers.
• A process for terminating the relationship, including how to extract customer data and migrate a run-
ning service to another CSP or an in-house solution.
SLAs may also specify consequences for breaches of the agreement – penalties for failure to meet SLA,
liability in the event of security compromise, etc. Moving liability for security to a CSP can signiﬁcantly
increase the CSP’s insurance cost and increase the price of the service.

5 Network Architecture of Cloud Computing
Figure 1 illustrates the basic elements that impact cloud computing.
Figure 1: Cloud Computing Basic Network Architecture
In the Figure:
1. The central element is the public Internet, to which every participant connects and which none of the
participants control or trust.
2. The organization wishing to move one or more applications “to the cloud” operates a private network.
3. Users who need access to the organization’s IT systems and applications may be in one of three
types of locations, categorized by the network to which their computers are connected:
(a) Directly attached to the private corporate network.

(b) Directly attached to the Internet – for example working from home or while traveling.
(c) Attached to a partner’s corporate network (e.g., a partner’s employees).
4. Applications may be attached to the private corporate network or hosted at the cloud service provider
(CSP)’s network.
5. Each network – i.e., the private corporate network, the CSP’s network and any partner networks
are protected against attacks originating on the Internet by a firewall. It should be noted that each
firewall has a concept of an “inside network” and an “outside network,” in the sense that connections
originating from the inside typically are allowed while connections originating from the outside typically
are blocked. This is illustrated using green (permissive) and red (blocking) arrows at each firewall.
6. Each network is shown as having a perimeter, with trusted assets that need to be protected “inside”
and untrusted assets – but also resources with which communication is required – “outside.”

6 The Intersection of Cloud Computing and IAM
6.1 Identity as a service (IDaaS)
Cloud identity management or identity-as-a-service (IDaaS) is a new concept that actually means differ-
ent things to different people. Some of the valid but mutually contradictory definitions for IDaaS include
managing the identities and security entitlements of users:
1. On a cloud platform, using an identity management application that resides on a cloud platform.
2. On a cloud platform, using an identity management application inside a corporate network perimeter.
3. Inside a corporate network perimeter, using an identity management application that resides on a
cloud platform.
The services provided in any of the above combinations also vary from one definition to another and may
include any combination of:
1. Administrative: Managing persistent user accounts and entitlements.
2. Authentication: Providing single signon that spans two or more security domains.
3. Authorization: Making access control decisions in one security domain based on assertions about a
user issued in another domain.
6.2 Scenario analysis: identity administration and cloud computing
The following sections will explore the pros and cons of a variety of scenarios where IAM and cloud com-
puting interact. The scenarios are constructed by considering every combination of the following variables:
Users may be:
1. Inside the corporate perimeter.
2. Remote: working outside the corporate perimeter.
User identification and authorization may be provided by:
1. A directory or service inside the corporate perimeter (examples: Active Directory or using a one time
password token).
2. With the user, using a smart card.
3. In the cloud, using a consumer-oriented authentication service such as Google Applications or Face-
book.
Applications that users access may be:

1. Inside the corporate perimeter (i.e., SAP R/3).
2. In the cloud (i.e., SalesForce.com).
The IAM system which manages users, entitlements and authentication factors may be:
1. Inside the corporate perimeter.
2. In the cloud.
Please refer to Appendix A on Page 17 for a detailed analysis of every scenario for combinations of identity
administration and cloud computing.
Please refer to Appendix B on Page 49 for a detailed analysis of two scenarios regarding the interaction
between cloud computing and privileged password management.

7 Summary
There are many scenarios where cloud computing and identity management interact. Each scenario has
pros and cons, depending on issues such as the need for trust, network latency, bandwidth and reliability
between cloud providers and internal networks, user mobility and the different permeability of corporate
ﬁrewalls in the inbound vs. outbound directions.
This document should help architects to evaluate the suitability of a variety of solutions. Ultimately, the
appropriateness of any given scenario depends on business priorities and the need to integrate with existing
infrastructure.

APPENDICES

A Scenario Analysis: Identity Administration and Cloud Computing
Scenario 1
User location: Inside the corporate perimeter.
Identity / authentication provider: Inside the corporate perimeter.
Application / relying party location: Inside the corporate perimeter.
IAM system: Inside the corporate perimeter.
User Authentication System
Alberta OPERATOR’S LICENCE
No: 137669-669
Class: 5
Cond/End: A
Expires: 18 JAN 2008
0234-69472
ApplicationIdentity
Management
System
Private Corporate Network Cloud-based Software Provider’s Publc Network
Public
Internet
Figure 2: Scenario 1 architecture
• Description:
– This is the base case – nothing is in the cloud. It is included here for reference.
• Pros:
– This is the default configuration today, so is well understood and considered to be secure.
– Connectivity is simple: firewalls do not require special configuration to enable the IAM system to
manage users and entitlements.
– Connectivity is fast: communication between the IAM system and managed applications is rela-
tively local so enjoys high bandwidth and low latency.
– No contractual trust relationships need to be negotiated or managed.
• Cons:
– Traditional IT infrastructure, such as the directory, application and IAM system, is costly to deploy
and manage.

Scenario 2
IAM system: In the cloud.
No: 137669-669
Class: 5
Cond/End: A
0234-69472
Application Identity
Management
System
Public
Internet
• Description:
– The identity management system has been moved into the cloud but everything else – the user,
the directory he authenticates to and the applications he accesses remain within the perimeter.
• Pros:
– A dedicated CSP can presumably host the IAM system at lower cost and with better expertise
than an internal IT organization.
• Cons:
– Traditional IT infrastructure, such as the directory and application, is costly to deploy and manage.
– Firewall rules must be changed to allow the external IAM system to connect to the internal di-
rectory and application. This may not be allowed – for example, in the case of network protocols
that carry plaintext passwords – in which case additional infrastructure is required inside the
perimeter, to proxy connections into internal systems using a more secure protocol.
– The network connection between the external IAM system and the internal directory and ap-
plication may be slower than a purely internal link. This may impact the performance of bulk
processes, such as auto-discovery and batch creation of users.
– Trust in the CSP operating the IAM system is essential and must be (a) based in a contract and
(b) validated.

Scenario 3
Application / relying party location: In the cloud or at a partner site.
No: 137669-669
Class: 5
Cond/End: A
0234-69472
ApplicationIdentity
Management
System
Public
Internet
• Description:
– The enterprise has moved one or more applications out of the perimeter, into the public cloud.
Everything else – the user, the directory and the IAM system – remain inside the perimeter. All
that’s needed to make this scenario work is connectors in the IAM system to manage users,
entitlements and passwords on applications that happen to be outside the perimeter. Federation
also works well in this scenario, as described in item 2 on Page 5.
• Pros:
– A dedicated CSP can presumably host the application at lower cost and with better expertise
• Cons:
– Traditional IT infrastructure, such as the directory and IAM system, is costly to deploy and man-
age.
– Trust in the CSP operating each application is essential and must be (a) based in a contract and
(b) validated.

Scenario 4
No: 137669-669
Class: 5
Cond/End: A
0234-69472
ApplicationIdentity
Management
System
Public
Internet
• Description:
– The enterprise deploys some cloud-based applications, and has decided to deploy the IAM sys-
tem in the cloud as well. The directory (e.g., AD) remains internal, however.
• Pros:
– A dedicated CSP can presumably host the application and IAM system at lower cost and with
better expertise than an internal IT organization.
• Cons:
– Traditional IT infrastructure, such as the directory, is costly to deploy and manage.
– Firewall rules must be changed to allow the external IAM system to connect to the internal direc-
tory. This may not be allowed – for example, in the case of network protocols that carry plaintext
passwords – in which case additional infrastructure is required inside the perimeter, to proxy
connections into internal systems using a more secure protocol.
– The network connection between the external IAM system and the internal directory may be
slower than a purely internal link. This may impact the performance of bulk processes, such as
auto-discovery and batch creation of users.
(b) validated.
(b) validated.

Scenario 5
Identity / authentication provider: With the user (i.e., a smart card). Note: there is almost certainly
still a directory inside the perimeter.
No: 137669-669
Class: 5
Cond/End: A
0234-69472
ApplicationIdentity
Management
System
Public
Internet
Smart Card
• Description:
– This is a baseline scenario where users sign in with a smart card (i.e., do not need to contact a
central directory to authenticate) but all the systems are internal.
• Pros:
– Strong, convenient authentication.
• Cons:
and manage.
– If the smart card is lost or stolen or if the user tries to authenticate from a device that does not
have a smart card reader, access is either awkward or impossible.

Scenario 6
No: 137669-669
Class: 5
Cond/End: A
0234-69472
Management
System
Public
Internet
Smart Card
• Description:
– In this scenario, a user authenticates with a smart card. His applications and the directory are
inside the perimeter, but the IAM system is at a CSP.
• Pros:
• Cons:
(b) validated.

Scenario 7
No: 137669-669
Class: 5
Cond/End: A
0234-69472
ApplicationIdentity
Management
System
Public
Internet
Smart Card
• Description:
– In this scenario, the user has a smart card, applications are hosted by a CSP but the IAM system
remains within the perimeter.
• Pros:
• Cons:
age.
(b) validated.

Scenario 8
No: 137669-669
Class: 5
Cond/End: A
0234-69472
ApplicationIdentity
Management
System
Public
Internet
Smart Card
• Description:
– In this scenario, the user authenticates with a smart card. The directory is internal but both
applications the user signs into and the IAM system are external.
• Pros:
• Cons:
(b) validated.
(b) validated.

Scenario 9
Identity / authentication provider: In the cloud.
No: 137669-669
Class: 5
Cond/End: A
0234-69472
ApplicationIdentity
Management
System
Public
Internet
• Description:
– In this scenario, the traditional corporate directory is replaced by a cloud-hosted service. For
example, systems may authenticate an end user via his Google or Facebook account instead of
using a corporate Active Directory. To do this, corporate applications must be modiﬁed to accept
federated assertions from such external providers, perhaps through a single intermediary that
consolidates assertions about user identity from multiple providers. The identity management
system, which may have to map cloud-based identities to application access rights, remains
within the perimeter.
• Pros:
– Externalizing user authentication may simplify the onboarding process and reduce the amount
of infrastructure required to manage a directory of internal users – for example by leveraging
consumer-oriented services instead of a corporate directory.
– A dedicated CSP can presumably host the directory at lower cost and with better expertise than
an internal IT organization.
– Users may respond positively to the ability to use their consumer authentication credentials at
work, seeing this as a progressive, “Web 2.0” option.
• Cons:
– Traditional IT infrastructure, such as the application and IAM system, is costly to deploy and
manage.

– Trust in the CSP operating the authentication service is essential and must be (a) based in a
contract and (b) validated.
– Applications have to be retooled to accept assertions from an external service.
– Regulatory compliance or security ofﬁcers are unlikely to be willing to externalize authentication
to a consumer-oriented service.
– Authentication against a cloud-hosted service may be slower than traditional authentication against
a corporate user directory, leading to a poor user experience.

Scenario 10
No: 137669-669
Class: 5
Cond/End: A
0234-69472
Management
System
Public
Internet
• Description:
– In this scenario, the traditional corporate directory is replaced by a cloud-hosted service. In
addition, the IAM system which manages the user lifecycle and links external identities to internal
application IDs is also moved to the cloud.
• Pros:
– A dedicated CSP can presumably host the directory and IAM system at lower cost and with better
expertise than an internal IT organization.
• Cons:
– Traditional IT infrastructure, such as the application, is costly to deploy and manage.
(b) validated.

Scenario 11
No: 137669-669
Class: 5
Cond/End: A
0234-69472
ApplicationIdentity
Management
System
Public
Internet
• Description:
– In this scenario, the traditional corporate directory is replaced by a cloud-hosted service. Appli-
cations are also moved to the cloud, where they can more readily consume assertions from the
Internet-based authentication service.
• Pros:
– A dedicated CSP can presumably host the directory and application at lower cost and with better
• Cons:
– Traditional IT infrastructure, such as the IAM system, is costly to deploy and manage.
(b) validated.

Scenario 12
No: 137669-669
Class: 5
Cond/End: A
0234-69472
ApplicationIdentity
Management
System
Public
Internet
• Description:
– This is a “pure cloud” arrangement – the only thing that stays within the corporate perimeter is
the user. IT has become totally virtualized in this arrangement, with each function ofﬂoaded to a
specialized application or service vendor.
• Pros:
– A dedicated CSP can presumably host the directory, application and IAM system at lower cost
and with better expertise than an internal IT organization.
• Cons:
(b) validated.
(b) validated.

Scenario 13
User location: Remote: working outside the corporate perimeter.
User
Authentication System
No: 137669-669
Class: 5
Cond/End: A
0234-69472
ApplicationIdentity
Management
System
Public
Internet
• Description:
– This is the standard “road warrior” or “work from home” scenario, where the IT infrastructure is
inside the corporate perimeter. Cloud computing is not really an element here – this is a baseline
case.
• Pros:
– No contractual trust relationships need to be negotiated or managed.
• Cons:
– Remote access to the internal directory, application and IAM system requires a VPN - which may
be costly to deploy and maintain.
and manage.

Scenario 14
User
No: 137669-669
Class: 5
Cond/End: A
0234-69472
Management
System
Public
Internet
• Description:
– In this scenario, the user is remote as is the IAM system. The corporate directory (typically AD)
and applications remain within the corporate perimeter.
• Pros:
• Cons:
– Remote access to the internal directory and application requires a VPN - which may be costly to
deploy and maintain.
(b) validated.

Scenario 15
User
No: 137669-669
Class: 5
Cond/End: A
0234-69472
ApplicationIdentity
Management
System
Public
Internet
• Description:
– This is a variation on the standard “road warrior” scenario, where some applications (example:
SalesForce.com) have been moved to a CSP or SaaS model.
• Pros:
– Depending on how the cloud-hosted application is conﬁgured, a VPN may not be needed by
remote users. Speciﬁcally, if the cloud-hosted application has its own local copy of the user/-
password database, then users can sign in from anywhere, without having to communicate with
the corporate directory.
• Cons:
– Remote access to the internal directory and IAM system requires a VPN - which may be costly
to deploy and maintain.
age.
(b) validated.

Scenario 16
User
No: 137669-669
Class: 5
Cond/End: A
0234-69472
ApplicationIdentity
Management
System
Public
Internet
• Description:
– In this scenario, the organization maintains a corporate directory inside the perimeter, but every-
thing else moves outside – including the user, who needs to work away from the office.
• Pros:
– Depending on how the cloud-hosted application is configured, a VPN may not be needed by
remote users. Specifically, if the cloud-hosted application has its own local copy of the user/-
password database, then users can sign in from anywhere, without having to communicate with
the corporate directory.
• Cons:
– Remote access to the internal directory requires a VPN - which may be costly to deploy and
maintain.
– Traditional IT infrastructure, such as the directory, is costly to deploy and manage.

(b) validated.
(b) validated.

Scenario 17
ApplicationIdentity
Management
System
Public
Internet
User
No: 137669-669
Class: 5
Cond/End: A
0234-69472
Smart
Card
• Description:
– In this scenario, a “road warrior” authenticates to his laptop and on-line applications with a smart
card. Applications and the IAM system remain inside the perimeter.
• Pros:
• Cons:
– Remote access to the internal directory, application and IAM system requires a VPN - which may
be costly to deploy and maintain.
and manage.

Scenario 18
Management
System
Public
Internet
User
No: 137669-669
Class: 5
Cond/End: A
0234-69472
Smart
Card
• Description:
– In this scenario, a “road warrior” authenticates to his laptop and on-line applications with a smart
card. Applications remain inside the perimeter but the IAM system is relocated to a CSP.
• Pros:
• Cons:
– Remote access to the internal directory and application requires a VPN - which may be costly to
deploy and maintain.

(b) validated.

Scenario 19
ApplicationIdentity
Management
System
Public
Internet
User
No: 137669-669
Class: 5
Cond/End: A
0234-69472
Smart
Card
• Description:
– In this scenario, a remote user authenticates with a smart card and accesses applications “in the
cloud.” This may free application access from his corporate laptop and VPN.
• Pros:
• Cons:
age.
(b) validated.

Scenario 20
User
No: 137669-669
Class: 5
Cond/End: A
0234-69472
ApplicationIdentity
Management
System
Public
Internet
Smart
Card
• Description:
– In this scenario, everything is remote – the user is outside the ofﬁce, applications are in the cloud,
authentication happens with a smart card and the IAM system is outside. In all likelihood, the
only component that remains inside the perimeter is a corporate directory against which smart
card credentials are linked.
• Pros:
• Cons:
(b) validated.

(b) validated.

Scenario 21
User
No: 137669-669
Class: 5
Cond/End: A
0234-69472
ApplicationIdentity
Management
System
Public
Internet
• Description:
– In this scenario, the user is remote and signs into corporate systems with cloud-based credentials
(e.g., Google Apps, Facebook, etc.). Applications and the IAM system remain internal.
• Pros:
– A dedicated CSP can presumably host the directory at lower cost and with better expertise than
an internal IT organization.
• Cons:
– Remote access to the internal application and IAM system requires a VPN - which may be costly
to deploy and maintain.
– Traditional IT infrastructure, such as the application and IAM system, is costly to deploy and
manage.

Scenario 22
User
No: 137669-669
Class: 5
Cond/End: A
0234-69472
Management
System
Public
Internet
• Description:
– In this scenario, everything except for some applications moves out to the cloud. The rationale
may be that while virtualizing the IT infrastructure is desirable, some applications simply have
too high a risk proﬁle to be moved outside the perimeter.
• Pros:
– A dedicated CSP can presumably host the directory and IAM system at lower cost and with better
• Cons:
– Remote access to the internal application requires a VPN - which may be costly to deploy and
maintain.
– Traditional IT infrastructure, such as the application, is costly to deploy and manage.
(b) validated.

Scenario 23
User
No: 137669-669
Class: 5
Cond/End: A
0234-69472
ApplicationIdentity
Management
System
Public
Internet
• Description:
– In this scenario, everything except for the IAM system is moved into the cloud. The scenario
is provided mainly for completeness, as it is unlikely that an organization willing to move their
corporate directory to a virtual infrastructure would nonetheless maintain an internal IAM system.
• Pros:
– A dedicated CSP can presumably host the directory and application at lower cost and with better
• Cons:
– Traditional IT infrastructure, such as the IAM system, is costly to deploy and manage.
(b) validated.

Scenario 24
User
No: 137669-669
Class: 5
Cond/End: A
0234-69472
ApplicationIdentity
Management
System
Public
Internet
• Description:
– In this scenario, everything is virtualized – users sign into cloud-based applications with cloud-
based credentials, managed using a cloud-based IAM system. This makes sense for small
organizations, for example, who cannot afford their own IT infrastructure and can operate with
the implied risk of consumer-based authentication services.
• Pros:
– A dedicated CSP can presumably host the directory, application and IAM system at lower cost
and with better expertise than an internal IT organization.
• Cons:
(b) validated.
(b) validated.

B Scenario Analysis: Privileged Password Management
A privileged ID management system controls access to login accounts that have elevated security rights. It
typically controls access to administrator IDs, service accounts and accounts used by one system to sign
into another.
Privileged ID management systems typically randomize passwords to sensitive IDs, store current passwords
in an encrypted vault, connect authorized people and programs to privileged accounts and audit this activity.
A privileged ID management system usually does not create privileged accounts, since that is almost always
a side effect of installing the system on which they exist. Similarly, these IDs are normally removed when a
system is uninstalled.
The following sections examine scenarios where privileged password management (also referred to as
privileged account management or privileged ID management) interacts with cloud computing.
B.1 Backup vault in the cloud
A privileged password management system normally works by frequently randomizing passwords to privi-
leged accounts and storing these passwords in a secure vault.
To avoid data loss in the event of a problem with an individual server or a whole data center, it is important to
store every privileged password in at least two physical vaults, preferably located in separate data centers.
Replication across multiple sites is difﬁcult to manage for organizations that only have a single data center.
Cloud computing offers an opportunity to address this, by placing a backup vault with encrypted data at a
cloud service provider’s facility.
Privileged
Password
Manager
Vault
Privileged
Password
Manager
Vault
Public
Internet
Figure 26: Using a CSP to replicate a privileged password vault
B.2 Securing administrative access to cloud infrastructure
Cloud service providers operate large numbers of servers, typically in the form of virtual machines. This
means that they have many privileged accounts to manage:

1. On virtual machine host servers.
2. On virtual machine operating system images.
3. On database and application servers.
4. On network infrastructure (routers, switches, etc.).
The large number of privileged passwords means that a privileged password management system can
signiﬁcantly reduce the operating overhead and signiﬁcantly improve the security of a CSP’s services.
Privileged
Password
Manager
Vault
Public
Internet
Application
Figure 27: Managing access to CSP systems with a privileged password management system
www.Hitachi-ID.com
500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 Fax: 1.403.233.0725 E-Mail: sales@Hitachi-ID.com
File: /pub/wp/documents/iam-in-the-cloud/iam-in-the-cloud-6.tex
Date: 2010-10-04

The Intersection of Identity Management and Cloud Computing

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie The Intersection of Identity Management and Cloud Computing

Ähnlich wie The Intersection of Identity Management and Cloud Computing (20)

Mehr von Hitachi ID Systems, Inc.

Mehr von Hitachi ID Systems, Inc. (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

The Intersection of Identity Management and Cloud Computing