Cloud Identity Buyer's Guide
Cloud Identity Buyer's Guide
Cloud Identity Buyer's Guide
Paper Focus:
Outsourcing identity and access management to the cloud IAM for SaaS apps tradeoffs and concerns Implementation, integration and operational requirements Cloud Service Broker technologies Detailed sample RFP template
Abstract
In this Buyers Guide, Intel discusses how your organization can deploy and manage an effective, efficient identity and access management solution for cloud applications.
1: Executive Summary
The software-as-a-service (SaaS)1 application delivery model is growing rapidly. SaaS is taking over the world. Thats the good news. However, customers who adopt the SaaS model struggle to manage the overwhelming number of user accounts they have to create. Their users are constantly forgetting their passwords and calling the help desk. They are unhappy because they have to reenter their user ID and password every time they logon to an application during the day. Overwhelmed IT administrators take too long to create accounts for new users. When a user leaves the organization their SaaS accounts remain active, increasing the risk of data exposure. All this consumes resources, increases enterprise risk, and costs your organization time, money and effort. You need help to reduce the complexity of managing the hundreds or thousands of SaaS accounts your users require, not just employees, but others too, like contractors, partners, distributors and customers. This Buyers Guide discusses the issue of identity and access management (IAM) for cloud applications. It outlines the issues that need to be addressed, suggests some approaches to solving those issues and wraps up with an overview of the products from Intel that are designed to help companies manage their SaaS account identities more effectively and efficiently.
2: Problem Statement
Enterprises of all sizes are embracing cloud computing because of the many advantages it provides. These include lower costs, greater business agility, reduced IT administrative overhead, access to best-of-breed applications, and more. Industry analyst firm IDC reports the SaaS market reached $16.6 billion in revenue in 2010 and is projected to grow at more than 25% per year between now and 2015. The cloud contains solutions that address virtually any conceivable business need: sales, marketing, human resources, collaboration and communication, finance, legal, etc. However, this proliferating profusion of solutions has created a daunting operational challenge: how to efficiently manage the profusion of identities that users require one for each cloud application they access. If you have 1,000 employees, each accessing 10 cloud applications on average, thats 10,000 unique identities to manage. In the Cloud Computing Technology Roadmap, the National Institute of Standards and Technology (NIST) advises, the need for trusted identities and secure and efficient management of these identities while users privacy is protected is a key element for the successful adoption of any cloud solution.2 The best way to address these concerns is to deploy strong identity management processes and technologies to ensure that only authorized users have access to cloud applications. In this Cloud Identity Buyers Guide, Intel discusses how your organization can design, deploy and manage an effective, efficient identity and access management solution for SaaS applications in two different scenarios: To the cloud IAM for SaaS applications from an on-premise platform In the cloud IAM for SaaS applications from an on-demand platform
the need for trusted identities and secure and efficient management of these identities while users privacy is protected is a key element for the successful adoption of any cloud solution. National Institute of Standards and Technology
Au
User
the
nti cat io
ib Attr
utes
1 2
See Appendix II - Industry Glossary & Acronyms on pg. 18. US Government Cloud Computing Technology Roadmap, Volume I, National Institute of Standards and Technology, Special Publication 500-293, Nov. 2011
We discuss some of the technologies available to: Manage the end-user identity lifecycle from creation to termination. Provide users with greater convenience by eliminating the need for them to remember user ID and passwords for multiple systems. Protect sensitive systems with strong multi-factor authentication. Empower IT administrators to easily monitor and manage all SaaS access activities and ensure compliance with relevant regulations. We evaluate various identity management standards, such as Service Provisioning Markup Language (SPML), Security Assertion Markup Language (SAML), OpenID, and OAuth which help ensure
Au
User
the
nti cat io
n
Account Sync SaaS Apps
Active Directory
ib Attr
utes
IAM System
that the ability to access enterprise SaaS solutions will keep pace as the industry matures. By making these fundamental capabilities an essential part of your overall cloud
initiative, you will be able to enjoy the many benefits of the cloud, while simultaneously protecting your vital corporate assets from unauthorized access, improving your users cloud experience, and controlling costs.
Implementing Internet SSO gives you the ability to provide users with access to hundreds of external sites using a single set of credentials, through a single portal. If those credentials are compromised, then all the target sites are at risk. In this use case, where simply entering a
user ID/password may not be sufficient protection, MFA provides an excellent strategy to protect multiple apps by controlling access to the SSO portal. It enables your organization to secure the cloud-based portal, bringing it up to enterprise security standards.
This need has led to the emergence of various strong authentication technologies, as listed in Table 1.
Table 1: Multi-factor Authentication Technologies APPROACH Biometrics DESCRIPTION Relies on physical characteristics (iris, fingerprint, voiceprint, etc.) of the user. High administrative overhead expensive to deploy, configure and maintain. Limited portability. Inflexible typically linked to a single application or entry point. Hardware Token Uses a dedicated device, such as an RSA* SecureID* token. Proprietary solution may be complicated to install, configure, distribute and manage. Insecure - customers have to replace all their tokens in the event the vendor sustains a breach. Typically configured for a single application, which limits usefulness when you are deploying multiple cloud applications using multiple service providers. Software Token Based on something your user (employee, contractor, customer, business partner, etc.) probably already has. Low management overhead doesnt require you to purchase, distribute and manage multiple single-use hardware devices. Flexible can be delivered through multiple channels: smart phone app, SMS text message, email, IM, Skype, etc. Secure service provider doesnt hold seeds that can be compromised.
Over the past few years, soft token technology has emerged which leverage something your users probably already have their cell phone or other mobile device. Soft tokens have a number of advantages over hardware tokens, including the fact that they can be
delivered via a variety of out-of-band channels. 2.1.3: Identity Lifecycle Management Identity lifecycle management encompasses all the activities that IT administrators and security personnel
perform to manage the user accounts from creating a SaaS application account to terminating it when the user leaves the organization. This identity lifecycle is often referred to as the CReate-UpdateDelete (CRUD) process.
Table 2: Identity Lifecycle Stages STAGE Create DESCRIPTION Provisioning new hires quickly is important, since a delay in provisioning users results in a loss of employee productivity. Other employee lifecycle events, such as open enrollment for healthcare benefits, can also drive the need to create large numbers of identities in a relatively short period of time. As your users attributes change (e.g., transfer to another department or relocation to a new office), they should be updated in their identity profile, where appropriate. When your employee leaves the organization, you need a mechanism to delete or disable their accounts on the target system(s). Otherwise, your organization risks allowing non-employees to access corporate data through these orphan accounts. Orphan accounts can also cost money in excess license or subscription fees.
Update Delete
Ordinarily, when a new employee comes on board, your IT administrator or application owner must use the SaaS application management interface to create an account for your users containing their user ID, password, and other useful attributes (department, phone number, manager, location, etc.) This process, which is the first step in the CRUD cycle, is typically referred to as provisioning. Over time, employee attributes change, which often requires updates to their application profiles.
Finally, the employee leaves the organization, which results in the need to block them from being able to access sensitive SaaS apps. The effort and expense required to manage the CRUD process is affected by a number of factors: number of employees, number and variety of target SaaS applications, employee turnover, and seasonal hiring/firing patterns. As companies expand over time, they typically reach a point where the cost and inconvenience required to manage this process becomes high enough that it makes sense to consider automating it.
Other features provided by automation can include a management console which provides provisioning/de-provisioning tools, as well as the ability to monitor user access activities, generate alerts and collect event data logs. Logs can be used for various purposes, such as capacity planning, audit and compliance reporting. The latter are particularly important in certain regulated industries.
3: Use Case and Integration Requirements 3.1: SSO for Cloud Apps
Cloud SSO improves end-user convenience and productivity users log on once to a trusted, secure portal controlled by their enterprise (either on-premise or in the cloud), and access authorized SaaS applications with a single click. Cloud single sign-on requires a high degree of integration between the IAM/ SSO system and the target application(s). The Security Assertion Markup Language (SAML) is the standard of choice for authentication and authorization between domains. SAML has several important attributes: SAML is a widely adopted standard which is supported by most major SaaS application vendors. SAML is based on a proven federated trust model. SAML doesnt require a password. A SAML-protected service provider relies on the ability of a trusted identity provider to verify a users identity. Table 3: Saas Authentication Models AUTHENTICATION SAML DESCRIPTION Uses industry-standard assertions (SAML token) provided by trusted target platforms, ensuring future compatibility as technology evolves; reduces risk (since SAML assertions contain no passwords) and address cloud identity regulatory compliance concerns. OpenID is used by a resource provider (typically a web site) to authenticate a user by redirecting the users browser to an identity provider, which provides an authentication token used to obtain access. OpenID is designed for use over HTTP, so its use is limited to browsers. Unlike OpenID, OAuth is designed to be protocol-independent. Applications using OAuth can theoretically request/ receive authentication tokens through a REST API using various protocols, including SAML, JSON (JavaScript Object Notation) or proprietary APIs. Thousands of SaaS applications require users to authenticate by entering a user ID/password via a web form. SSO that works with HTTP forms enables the user to enter their user ID and password once. Their credentials are then stored in a secure password vault and transparently replayed whenever the user logs in after that. A smaller number of applications support SSO by exposing an API that can be called by the SSO software.
Federated SSO
SaaS Apps
Ideally, the solution should provide out-of-the-box SSO for a wide variety of popular SaaS applications. Buyers should seek out SaaS solutions which support SAML and ensure that their IAM solution also supports it in order to provide the foundation for secure federated SSO. Other authentication standards to consider include OAuth and OpenID. Most standards-based SSO is sometimes referred to as federated SSO, since there is a trusted relationship between the user and the various systems responsible for authentication.
If a SaaS application vendor does not support federated SSO using a standard, such as SAML, OAuth or OpenID, they may provide support for HTTP forms authentication or a proprietary API. When considering an IAM solution for SaaS, make sure the vendor supports the authentication model(s) supported by your SaaS app vendors.
OpenID
OAuth
HTTP Forms
Native API
User
OTP
IAM System
SaaS Apps
selectively invoke MFA in particular scenarios. For example, it may make sense to invoke MFA for a specific group of users; when a user is in an insecure location or on a public network; or is accessing the SaaS application from a previously unknown device or IP address. Context-aware authentication allows you to define business rules that selectivelly enforce MFA, based on user identityrelated attributes.
There may be instances where the identity attributes of different categories of users are stored in different repositories. An organization may keep the identities of regular employees in an HR system of record, contractor identities in a relational database, and customer identities in a customer relationship management system, such as Salesforce*. Its also not unusual for a single users identity attributes to be stored in multiple locations, such as an employee name, ID #, manager, location, phone number in the HR system of record, while their network user ID, network password and email address are stored in AD. When evaluating your integration requirements, it may be necessary to examine multiple systems to determine where relevant user identity attributes are stored. Integration with internal repositories addresses multiple purposes: provisioning, profile synchronization, and authentication. For example, when provisioning a SaaS account for a user, the attributes in the various repositories
may be passed along to the target system, and kept in synch with the target system as they change over time (e.g., a user transfers between departments or moves to a new location.) Centralized user authentication relies on the user being authenticated once when they log onto their PC or a network. Once the user is reliably authenticated, that can provide the basis for enabling secure SSO to various target SaaS applications. Regardless of which scenario (IAM in the cloud or on-premise) is used, the basic lifecycle is the same: an administrator uses the system to establish one or more SaaS application accounts on behalf of users, manages those accounts over time, and deletes or disables the accounts when the user leaves the organization. You should evaluate the ability of each vendor to support both provisioning AND deprovisioning for key SaaS applications. 3.3.1: Provisioning Standards The Service Provisioning Markup Language (SPML) standard was established to facilitate a vendorneutral process for provisioning and
managing accounts on target applications. Unfortunately, it is not widely supported by application vendors. As a result, IAM solution vendors have needed to create customized provisioning interfaces for each target application. Recently the Simple Cloud Identity Management (SCIM) provisioning protocol has emerged. This new protocol is expected to be supported by influential SaaS providers, including Salesforce and Google. Given the uncertain state of provisioning standards, you should carefully evaluate what provisioning capabilities are exposed by your SaaS vendors and whether the IAM solution you are considering supports those capabilities. Otherwise, you will need to work with your IAM vendor to create and maintain customized provisioning connectors.
10
3.4.2: SSO Portal Many organizations provide employees with access to an enterprise portal used to provide convenient access to various applications. Common examples include IBM Websphere*, Oracle WebLogic* and Microsoft Sharepoint*. In many instances, the portal is responsible for authentication of a users identity, or it may rely on another authentication system, such as Windows. When selecting an on-premise IAM system, you should ensure that it will be compatible with your existing or planned enterprise portals. Implementing an IAM system that supports your enterprise portal enables you to create personalized portal pages, where authenticated users can have secure access to the various SaaS applications they are authorized to use. One advantage of using a personalized SSO portal approach is that users can be blocked from access to apps they are not authorized to use.
The same approach can be taken to an on-demand SSO portal by providing users with a personalized landing page in the cloud. Once the user authenticates to the page, they will see all the SaaS applications they are authorized to access and click on the icon to log on.
In todays cloud access environment, it has become standard to provide users with access to dozens or hundreds of pre-configured cloud apps. During the evaluation process, determine whether or not your vendor can provide this capability, since without it, your IT team will have to design and implement web links and other features of the portal.
11
12
13
14
15
16
17
18
PaaS SaaS
Platform-as-a-Service Software-as-a-service
Security Assertion Markup Language Simple Cloud Identity Management Service Provisioning Markup Language eXtensible Access Control Markup Language
XACML
19
More Information
Intel Cloud SSO: intelcloudsso.com McAfee: www.mcafee.com/cim Phone: +1-651-628-5352 email: identity@mcafee.com
McAfee and the McAfee logo are registered trademarks or trademarks of McAfee, Inc. or its subsidiaries in the United States and other countries. Other marks and brands may be claimed as the property of others. The product plans, specifications and descriptions herein are provided for information only and subject to change without notice, and are provided without warranty of any kind, express or implied. Copyright 2012 McAfee, Inc.