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” . . . . . . . . . . . . . . . . . ....
The Intersection of Identity Management and Cloud Computing
6.1 Identity as a service (IDaaS) . . . . . . . . . . . . . . ...
The Intersection of Identity Management and Cloud Computing
1 Introduction
This document is a comprehensive analysis of al...
The Intersection of Identity Management and Cloud Computing
2 Background: Cloud Computing and IAM
2.1 The term “cloud”
The...
The Intersection of Identity Management and Cloud Computing
2. A community cloud might be established when several organiz...
The Intersection of Identity Management and Cloud Computing
2.3.1 Identity administration vs. runtime access control
The t...
The Intersection of Identity Management and Cloud Computing
1. Web access management / web single signon (WebAM) authentic...
The Intersection of Identity Management and Cloud Computing
3 Benefits of Cloud Computing
3.1 Lower, predictable costs
Cust...
The Intersection of Identity Management and Cloud Computing
3.5 Faster provisioning
In many organizations, it can take wee...
The Intersection of Identity Management and Cloud Computing
4 Drawbacks of Cloud Computing
4.1 Control and dependence on t...
The Intersection of Identity Management and Cloud Computing
agreements with EU member states. Another jurisdictional chall...
The Intersection of Identity Management and Cloud Computing
2. Even CSPs that remain viable businesses may discontinue spe...
The Intersection of Identity Management and Cloud Computing
5 Network Architecture of Cloud Computing
Figure 1 illustrates...
The Intersection of Identity Management and Cloud Computing
(b) Directly attached to the Internet – for example working fr...
The Intersection of Identity Management and Cloud Computing
6 The Intersection of Cloud Computing and IAM
6.1 Identity as ...
The Intersection of Identity Management and Cloud Computing
1. Inside the corporate perimeter (i.e., SAP R/3).
2. In the c...
The Intersection of Identity Management and Cloud Computing
7 Summary
There are many scenarios where cloud computing and i...
The Intersection of Identity Management and Cloud Computing
APPENDICES
© 2011 Hitachi ID Systems, Inc. All rights reserved...
The Intersection of Identity Management and Cloud Computing
A Scenario Analysis: Identity Administration and Cloud Computi...
The Intersection of Identity Management and Cloud Computing
Scenario 2
User location: Inside the corporate perimeter.
Iden...
The Intersection of Identity Management and Cloud Computing
Scenario 3
User location: Inside the corporate perimeter.
Iden...
The Intersection of Identity Management and Cloud Computing
Scenario 4
User location: Inside the corporate perimeter.
Iden...
The Intersection of Identity Management and Cloud Computing
Scenario 5
User location: Inside the corporate perimeter.
Iden...
The Intersection of Identity Management and Cloud Computing
Scenario 6
User location: Inside the corporate perimeter.
Iden...
The Intersection of Identity Management and Cloud Computing
Scenario 7
User location: Inside the corporate perimeter.
Iden...
The Intersection of Identity Management and Cloud Computing
Scenario 8
User location: Inside the corporate perimeter.
Iden...
The Intersection of Identity Management and Cloud Computing
– If the smart card is lost or stolen or if the user tries to ...
The Intersection of Identity Management and Cloud Computing
Scenario 9
User location: Inside the corporate perimeter.
Iden...
The Intersection of Identity Management and Cloud Computing
– Trust in the CSP operating the authentication service is ess...
The Intersection of Identity Management and Cloud Computing
Scenario 10
User location: Inside the corporate perimeter.
Ide...
The Intersection of Identity Management and Cloud Computing
– Authentication against a cloud-hosted service may be slower ...
The Intersection of Identity Management and Cloud Computing
Scenario 11
User location: Inside the corporate perimeter.
Ide...
The Intersection of Identity Management and Cloud Computing
Scenario 12
User location: Inside the corporate perimeter.
Ide...
The Intersection of Identity Management and Cloud Computing
Scenario 13
User location: Remote: working outside the corpora...
The Intersection of Identity Management and Cloud Computing
Scenario 14
User location: Remote: working outside the corpora...
The Intersection of Identity Management and Cloud Computing
Scenario 15
User location: Remote: working outside the corpora...
The Intersection of Identity Management and Cloud Computing
Scenario 16
User location: Remote: working outside the corpora...
The Intersection of Identity Management and Cloud Computing
– Trust in the CSP operating the IAM system is essential and m...
The Intersection of Identity Management and Cloud Computing
Scenario 17
User location: Remote: working outside the corpora...
The Intersection of Identity Management and Cloud Computing
Scenario 18
User location: Remote: working outside the corpora...
The Intersection of Identity Management and Cloud Computing
– Trust in the CSP operating the IAM system is essential and m...
The Intersection of Identity Management and Cloud Computing
Scenario 19
User location: Remote: working outside the corpora...
The Intersection of Identity Management and Cloud Computing
Scenario 20
User location: Remote: working outside the corpora...
The Intersection of Identity Management and Cloud Computing
– Trust in the CSP operating each application is essential and...
The Intersection of Identity Management and Cloud Computing
Scenario 21
User location: Remote: working outside the corpora...
The Intersection of Identity Management and Cloud Computing
– Applications have to be retooled to accept assertions from a...
The Intersection of Identity Management and Cloud Computing
Scenario 22
User location: Remote: working outside the corpora...
The Intersection of Identity Management and Cloud Computing
– Applications have to be retooled to accept assertions from a...
The Intersection of Identity Management and Cloud Computing
Scenario 23
User location: Remote: working outside the corpora...
The Intersection of Identity Management and Cloud Computing
Scenario 24
User location: Remote: working outside the corpora...
The Intersection of Identity Management and Cloud Computing
B Scenario Analysis: Privileged Password Management
A privileg...
The Intersection of Identity Management and Cloud Computing
1. On virtual machine host servers.
2. On virtual machine oper...
Upcoming SlideShare
Loading in …5
×

The Intersection of Identity Management and Cloud Computing

709 views
654 views

Published on

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.

Published in: Technology, Business
1 Comment
0 Likes
Statistics
Notes
  • download here link 100% working: https://app.box.com/s/olzwnk240vfm2ir8yfdw
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Views
Total views
709
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
63
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide

The Intersection of Identity Management and Cloud Computing

  1. 1. The Intersection of Identity Management and Cloud Computing © 2011 Hitachi ID Systems, Inc. All rights reserved.
  2. 2. 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 Benefits 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
  3. 3. 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.
  4. 4. The Intersection of Identity Management and Cloud Computing 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
  5. 5. The Intersection of Identity Management and Cloud Computing 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 fine-grained, self-service basis, accessible over the Internet. Usually the services are billed using a fine-grained utility computing model. 1The term utility is used here in the sense of an electricity grid or telephone service provider. © 2011 Hitachi ID Systems, Inc. All rights reserved. 2
  6. 6. The Intersection of Identity Management and Cloud Computing 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 © 2011 Hitachi ID Systems, Inc. All rights reserved. 3
  7. 7. The Intersection of Identity Management and Cloud Computing 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: © 2011 Hitachi ID Systems, Inc. All rights reserved. 4
  8. 8. The Intersection of Identity Management and Cloud Computing 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 5
  9. 9. The Intersection of Identity Management and Cloud Computing 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 6
  10. 10. The Intersection of Identity Management and Cloud Computing 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 7
  11. 11. The Intersection of Identity Management and Cloud Computing 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, fines 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 specific 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 © 2011 Hitachi ID Systems, Inc. All rights reserved. 8
  12. 12. The Intersection of Identity Management and Cloud Computing 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 difficult 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 9
  13. 13. The Intersection of Identity Management and Cloud Computing 2. Even CSPs that remain viable businesses may discontinue specific 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 significantly increase the CSP’s insurance cost and increase the price of the service. © 2011 Hitachi ID Systems, Inc. All rights reserved. 10
  14. 14. The Intersection of Identity Management and Cloud Computing 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 11
  15. 15. The Intersection of Identity Management and Cloud Computing (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.” © 2011 Hitachi ID Systems, Inc. All rights reserved. 12
  16. 16. The Intersection of Identity Management and Cloud Computing 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: © 2011 Hitachi ID Systems, Inc. All rights reserved. 13
  17. 17. The Intersection of Identity Management and Cloud Computing 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 14
  18. 18. The Intersection of Identity Management and Cloud Computing 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 firewalls 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 15
  19. 19. The Intersection of Identity Management and Cloud Computing APPENDICES © 2011 Hitachi ID Systems, Inc. All rights reserved. 16
  20. 20. The Intersection of Identity Management and Cloud Computing 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 17
  21. 21. The Intersection of Identity Management and Cloud Computing Scenario 2 User location: Inside the corporate perimeter. Identity / authentication provider: Inside the corporate perimeter. Application / relying party location: Inside the corporate perimeter. IAM system: In the cloud. User Authentication System Alberta OPERATOR’S LICENCE No: 137669-669 Class: 5 Cond/End: A Expires: 18 JAN 2008 0234-69472 Application Identity Management System Private Corporate Network Cloud-based Software Provider’s Publc Network Public Internet Figure 3: Scenario 2 architecture • 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 18
  22. 22. The Intersection of Identity Management and Cloud Computing Scenario 3 User location: Inside the corporate perimeter. Identity / authentication provider: Inside the corporate perimeter. Application / relying party location: In the cloud or at a partner site. 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 4: Scenario 3 architecture • 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: – Connectivity is simple: firewalls do not require special configuration to enable the IAM system to manage users and entitlements. – A dedicated CSP can presumably host the application at lower cost and with better expertise than an internal IT organization. • 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 19
  23. 23. The Intersection of Identity Management and Cloud Computing Scenario 4 User location: Inside the corporate perimeter. Identity / authentication provider: Inside the corporate perimeter. Application / relying party location: In the cloud or at a partner site. IAM system: In the cloud. 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 5: Scenario 4 architecture • 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. – Trust in the CSP operating the IAM system is essential and must be (a) based in a contract and (b) validated. – Trust in the CSP operating each application is essential and must be (a) based in a contract and (b) validated. © 2011 Hitachi ID Systems, Inc. All rights reserved. 20
  24. 24. The Intersection of Identity Management and Cloud Computing Scenario 5 User location: Inside the corporate perimeter. Identity / authentication provider: With the user (i.e., a smart card). Note: there is almost certainly still a directory inside the 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 Smart Card Figure 6: Scenario 5 architecture • 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. – Connectivity is fast: communication between the IAM system and managed applications is rela- tively local so enjoys high bandwidth and low latency. • Cons: – Traditional IT infrastructure, such as the directory, application and IAM system, is costly to deploy 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 21
  25. 25. The Intersection of Identity Management and Cloud Computing Scenario 6 User location: Inside the corporate perimeter. Identity / authentication provider: With the user (i.e., a smart card). Note: there is almost certainly still a directory inside the perimeter. Application / relying party location: Inside the corporate perimeter. IAM system: In the cloud. User Authentication System Alberta OPERATOR’S LICENCE No: 137669-669 Class: 5 Cond/End: A Expires: 18 JAN 2008 0234-69472 Application Identity Management System Private Corporate Network Cloud-based Software Provider’s Publc Network Public Internet Smart Card Figure 7: Scenario 6 architecture • 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: – Strong, convenient authentication. – 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. – 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 22
  26. 26. The Intersection of Identity Management and Cloud Computing Scenario 7 User location: Inside the corporate perimeter. Identity / authentication provider: With the user (i.e., a smart card). Note: there is almost certainly still a directory inside the perimeter. Application / relying party location: In the cloud or at a partner site. 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 Smart Card Figure 8: Scenario 7 architecture • 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: – Strong, convenient authentication. – A dedicated CSP can presumably host the application at lower cost and with better expertise than an internal IT organization. • 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. – 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 23
  27. 27. The Intersection of Identity Management and Cloud Computing Scenario 8 User location: Inside the corporate perimeter. Identity / authentication provider: With the user (i.e., a smart card). Note: there is almost certainly still a directory inside the perimeter. Application / relying party location: In the cloud or at a partner site. IAM system: In the cloud. 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 Smart Card Figure 9: Scenario 8 architecture • 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: – Strong, convenient authentication. – A dedicated CSP can presumably host the application and IAM system at lower cost and with better expertise than an internal IT organization. • Cons: – 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. – Trust in the CSP operating the IAM system is essential and must be (a) based in a contract and (b) validated. – Trust in the CSP operating each application is essential and must be (a) based in a contract and (b) validated. © 2011 Hitachi ID Systems, Inc. All rights reserved. 24
  28. 28. The Intersection of Identity Management and Cloud Computing – 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 25
  29. 29. The Intersection of Identity Management and Cloud Computing Scenario 9 User location: Inside the corporate perimeter. Identity / authentication provider: In the cloud. 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 10: Scenario 9 architecture • 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 modified 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: – Connectivity is fast: communication between the IAM system and managed applications is rela- tively local so enjoys high bandwidth and low latency. – 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 26
  30. 30. The Intersection of Identity Management and Cloud Computing – 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 officers 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 27
  31. 31. The Intersection of Identity Management and Cloud Computing Scenario 10 User location: Inside the corporate perimeter. Identity / authentication provider: In the cloud. Application / relying party location: Inside the corporate perimeter. IAM system: In the cloud. User Authentication System Alberta OPERATOR’S LICENCE No: 137669-669 Class: 5 Cond/End: A Expires: 18 JAN 2008 0234-69472 Application Identity Management System Private Corporate Network Cloud-based Software Provider’s Publc Network Public Internet Figure 11: Scenario 10 architecture • 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: – 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 and IAM system 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, is costly to deploy and manage. – Trust in the CSP operating the IAM system is essential and must be (a) based in a contract and (b) validated. – 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 officers are unlikely to be willing to externalize authentication to a consumer-oriented service. © 2011 Hitachi ID Systems, Inc. All rights reserved. 28
  32. 32. The Intersection of Identity Management and Cloud Computing – Authentication against a cloud-hosted service may be slower than traditional authentication against a corporate user directory, leading to a poor user experience. © 2011 Hitachi ID Systems, Inc. All rights reserved. 29
  33. 33. The Intersection of Identity Management and Cloud Computing Scenario 11 User location: Inside the corporate perimeter. Identity / authentication provider: In the cloud. Application / relying party location: In the cloud or at a partner site. 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 12: Scenario 11 architecture • 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 expertise than an internal IT organization. • Cons: – Traditional IT infrastructure, such as the 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. – Trust in the CSP operating each application is essential and must be (a) based in a contract and (b) validated. – Regulatory compliance or security officers 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 30
  34. 34. The Intersection of Identity Management and Cloud Computing Scenario 12 User location: Inside the corporate perimeter. Identity / authentication provider: In the cloud. Application / relying party location: In the cloud or at a partner site. IAM system: In the cloud. 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 13: Scenario 12 architecture • 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 offloaded 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: – Trust in the CSP operating the IAM system is essential and must be (a) based in a contract and (b) validated. – Trust in the CSP operating the authentication service is essential and must be (a) based in a contract and (b) validated. – Trust in the CSP operating each application is essential and must be (a) based in a contract and (b) validated. – Regulatory compliance or security officers 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 31
  35. 35. The Intersection of Identity Management and Cloud Computing Scenario 13 User location: Remote: working outside 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 14: Scenario 13 architecture • 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: – 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: – Remote access to the internal directory, application and IAM system requires a VPN - which may be costly to deploy and maintain. – Traditional IT infrastructure, such as the directory, application and IAM system, is costly to deploy and manage. © 2011 Hitachi ID Systems, Inc. All rights reserved. 32
  36. 36. The Intersection of Identity Management and Cloud Computing Scenario 14 User location: Remote: working outside the corporate perimeter. Identity / authentication provider: Inside the corporate perimeter. Application / relying party location: Inside the corporate perimeter. IAM system: In the cloud. User Authentication System Alberta OPERATOR’S LICENCE No: 137669-669 Class: 5 Cond/End: A Expires: 18 JAN 2008 0234-69472 Application Identity Management System Private Corporate Network Cloud-based Software Provider’s Publc Network Public Internet Figure 15: Scenario 14 architecture • 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: – A dedicated CSP can presumably host the IAM system at lower cost and with better expertise than an internal IT organization. • Cons: – Remote access to the internal directory and application requires a VPN - which may be costly to deploy and maintain. – 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 33
  37. 37. The Intersection of Identity Management and Cloud Computing Scenario 15 User location: Remote: working outside the corporate perimeter. Identity / authentication provider: Inside the corporate perimeter. Application / relying party location: In the cloud or at a partner site. 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 16: Scenario 15 architecture • 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: – Connectivity is simple: firewalls do not require special configuration to enable the IAM system to manage users and entitlements. – A dedicated CSP can presumably host the application at lower cost and with better expertise than an internal IT organization. – 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 and IAM system requires a VPN - which may be costly to deploy and maintain. – 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 34
  38. 38. The Intersection of Identity Management and Cloud Computing Scenario 16 User location: Remote: working outside the corporate perimeter. Identity / authentication provider: Inside the corporate perimeter. Application / relying party location: In the cloud or at a partner site. IAM system: In the cloud. 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 17: Scenario 16 architecture • 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: – A dedicated CSP can presumably host the application and IAM system at lower cost and with better expertise than an internal IT organization. – 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. – 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 35
  39. 39. The Intersection of Identity Management and Cloud Computing – Trust in the CSP operating the IAM system is essential and must be (a) based in a contract and (b) validated. – Trust in the CSP operating each application is essential and must be (a) based in a contract and (b) validated. © 2011 Hitachi ID Systems, Inc. All rights reserved. 36
  40. 40. The Intersection of Identity Management and Cloud Computing Scenario 17 User location: Remote: working outside the corporate perimeter. Identity / authentication provider: With the user (i.e., a smart card). Note: there is almost certainly still a directory inside the perimeter. Application / relying party location: Inside the corporate perimeter. IAM system: Inside the corporate perimeter. ApplicationIdentity Management System Private Corporate Network Cloud-based Software Provider’s Publc Network Public Internet User Authentication System Alberta OPERATOR’S LICENCE No: 137669-669 Class: 5 Cond/End: A Expires: 18 JAN 2008 0234-69472 Smart Card Figure 18: Scenario 17 architecture • 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: – Strong, convenient authentication. – Connectivity is fast: communication between the IAM system and managed applications is rela- tively local so enjoys high bandwidth and low latency. • Cons: – Remote access to the internal directory, application and IAM system requires a VPN - which may be costly to deploy and maintain. – Traditional IT infrastructure, such as the directory, application and IAM system, is costly to deploy 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 37
  41. 41. The Intersection of Identity Management and Cloud Computing Scenario 18 User location: Remote: working outside the corporate perimeter. Identity / authentication provider: With the user (i.e., a smart card). Note: there is almost certainly still a directory inside the perimeter. Application / relying party location: Inside the corporate perimeter. IAM system: In the cloud. Application Identity Management System Private Corporate Network Cloud-based Software Provider’s Publc Network Public Internet User Authentication System Alberta OPERATOR’S LICENCE No: 137669-669 Class: 5 Cond/End: A Expires: 18 JAN 2008 0234-69472 Smart Card Figure 19: Scenario 18 architecture • 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: – Strong, convenient authentication. – A dedicated CSP can presumably host the IAM system at lower cost and with better expertise than an internal IT organization. • Cons: – Remote access to the internal directory and application requires a VPN - which may be costly to deploy and maintain. – 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 38
  42. 42. The Intersection of Identity Management and Cloud Computing – Trust in the CSP operating the IAM system is essential and must be (a) based in a contract and (b) validated. – 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 39
  43. 43. The Intersection of Identity Management and Cloud Computing Scenario 19 User location: Remote: working outside the corporate perimeter. Identity / authentication provider: With the user (i.e., a smart card). Note: there is almost certainly still a directory inside the perimeter. Application / relying party location: In the cloud or at a partner site. IAM system: Inside the corporate perimeter. ApplicationIdentity Management System Private Corporate Network Cloud-based Software Provider’s Publc Network Public Internet User Authentication System Alberta OPERATOR’S LICENCE No: 137669-669 Class: 5 Cond/End: A Expires: 18 JAN 2008 0234-69472 Smart Card Figure 20: Scenario 19 architecture • 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: – Strong, convenient authentication. – A dedicated CSP can presumably host the application at lower cost and with better expertise than an internal IT organization. • 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. – 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 40
  44. 44. The Intersection of Identity Management and Cloud Computing Scenario 20 User location: Remote: working outside the corporate perimeter. Identity / authentication provider: With the user (i.e., a smart card). Note: there is almost certainly still a directory inside the perimeter. Application / relying party location: In the cloud or at a partner site. IAM system: In the cloud. 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 Smart Card Figure 21: Scenario 20 architecture • Description: – In this scenario, everything is remote – the user is outside the office, 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: – Strong, convenient authentication. – A dedicated CSP can presumably host the application and IAM system at lower cost and with better expertise than an internal IT organization. • Cons: – 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. – Trust in the CSP operating the IAM system is essential and must be (a) based in a contract and (b) validated. © 2011 Hitachi ID Systems, Inc. All rights reserved. 41
  45. 45. The Intersection of Identity Management and Cloud Computing – Trust in the CSP operating each application is essential and must be (a) based in a contract and (b) validated. – 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 42
  46. 46. The Intersection of Identity Management and Cloud Computing Scenario 21 User location: Remote: working outside the corporate perimeter. Identity / authentication provider: In the cloud. 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 22: Scenario 21 architecture • 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: – Connectivity is fast: communication between the IAM system and managed applications is rela- tively local so enjoys high bandwidth and low latency. – 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: – 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. – Trust in the CSP operating the authentication service is essential and must be (a) based in a contract and (b) validated. © 2011 Hitachi ID Systems, Inc. All rights reserved. 43
  47. 47. The Intersection of Identity Management and Cloud Computing – Applications have to be retooled to accept assertions from an external service. – Regulatory compliance or security officers 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 44
  48. 48. The Intersection of Identity Management and Cloud Computing Scenario 22 User location: Remote: working outside the corporate perimeter. Identity / authentication provider: In the cloud. Application / relying party location: Inside the corporate perimeter. IAM system: In the cloud. User Authentication System Alberta OPERATOR’S LICENCE No: 137669-669 Class: 5 Cond/End: A Expires: 18 JAN 2008 0234-69472 Application Identity Management System Private Corporate Network Cloud-based Software Provider’s Publc Network Public Internet Figure 23: Scenario 22 architecture • 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 profile to be moved outside 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 and IAM system 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: – 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. – Trust in the CSP operating the IAM system is essential and must be (a) based in a contract and (b) validated. – Trust in the CSP operating the authentication service is essential and must be (a) based in a contract and (b) validated. © 2011 Hitachi ID Systems, Inc. All rights reserved. 45
  49. 49. The Intersection of Identity Management and Cloud Computing – Applications have to be retooled to accept assertions from an external service. – Regulatory compliance or security officers 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 46
  50. 50. The Intersection of Identity Management and Cloud Computing Scenario 23 User location: Remote: working outside the corporate perimeter. Identity / authentication provider: In the cloud. Application / relying party location: In the cloud or at a partner site. 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 24: Scenario 23 architecture • 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 expertise than an internal IT organization. • Cons: – Traditional IT infrastructure, such as the 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. – Trust in the CSP operating each application is essential and must be (a) based in a contract and (b) validated. – Regulatory compliance or security officers 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 47
  51. 51. The Intersection of Identity Management and Cloud Computing Scenario 24 User location: Remote: working outside the corporate perimeter. Identity / authentication provider: In the cloud. Application / relying party location: In the cloud or at a partner site. IAM system: In the cloud. 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 25: Scenario 24 architecture • 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: – Trust in the CSP operating the IAM system is essential and must be (a) based in a contract and (b) validated. – Trust in the CSP operating the authentication service is essential and must be (a) based in a contract and (b) validated. – Trust in the CSP operating each application is essential and must be (a) based in a contract and (b) validated. – Regulatory compliance or security officers 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 48
  52. 52. The Intersection of Identity Management and Cloud Computing 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 difficult 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 Private Corporate Network Cloud-based Software Provider’s Publc Network 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: © 2011 Hitachi ID Systems, Inc. All rights reserved. 49
  53. 53. The Intersection of Identity Management and Cloud Computing 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 significantly reduce the operating overhead and significantly improve the security of a CSP’s services. Privileged Password Manager Vault Private Corporate Network Cloud-based Software Provider’s Publc Network 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

×