identity management as a service: deploying iam in a saas model

Identity Management as a Service

Deploying IAM in a SaaS Model

© 2014 Hitachi ID Systems, Inc. All rights reserved.

http://Hitachi-ID.com/

http://Hitachi.com/

Contents

1 Introduction 1

2 Background - IAM 1

3 Background - SaaS 2

4 Perimeter, firewalls and integrations 2

5 Risk assessment – identity data hosted by a third party 5

6 One identity administration system or two? 6

7 Federating authentication and authorization 6

8 Securing privileged accounts 8

8.1 Securing access to cloud computing infrastructure . . . . . . . . . . . . . . . . . . . . . . . 8

8.2 Leveraging cloud infrastructure for credential vault replication . . . . . . . . . . . . . . . . . 8

8.3 Connecting cloud-hosted applications to on-premise systems . . . . . . . . . . . . . . . . . 9

9 Multi-tenancy and standardized business processes 10

10 Identity management deployment patterns 11

10.1 Corporate model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

10.2 Higher education model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

10.3 Internet portal model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

11 Summary 13

i

Identity Management as a Service (IAM SaaS)

1 Introduction

This document discusses strategies for deploying an identity and access management system (IAM) usinga software as a service (SaaS) provider. It identifies business and technical challenges that arise when anIAM system is moved outside of an organization’s private network perimeter and offers solutions to addressthem.

Every medium to large organization can benefit from an IAM system. Many organizations are interested inmoving some of their IT infrastructure from private data centers to “the cloud” – which often is short-handfor software as a service (SaaS). It follows that many organizations will be interested in moving their existingIAM systems or deploying a new IAM system in a SaaS model.

2 Background - IAM

Identity and access management encompasses a wide range of solutions, including smart cards, bio-metrics, network access control devices, directories, software to manage users and entitlements both in-side an organization (business-to-employee) and externally (government-to-citizen, business-to-business,business-to-customer, etc.), enterprise single sign-on, web single sign-on, federation, authorization enginesand more.

This document’s primary focus is on systems that create, manage and deactivate the access of internalusers to systems and applications in medium to large organizations (1,000 to 300,000 users). This includesuser provisioning, access certification, password management and single sign-on applications designed fordeployments in the “business to employee” pattern.

This document also covers design considerations for federated access management systems that are de-ployed to corporate users in the same organizations.

Organizations deploy IAM systems in order to achieve a number of benefits, including:

1. To comply with a variety of regulations, which call for strong internal controls. Internal controls dependon IT security, which in turn depends on trustworthy user onboarding and deactivation processes,reliable authentication, appropriate security entitlements and detailed audit logs.

2. To lower IT operating expense, in particular relating to help desk services (reduce password reset callvolume) and security administration (automate access setup and tear-down).

3. To improve user service, through more user friendly and efficient change management, fewer pass-words for users to remember and streamlined application logins.

© 2014 Hitachi ID Systems, Inc.. All rights reserved. 1


3 Background - SaaS

Software as a service (SaaS) is both a business model and a technology deployment pattern. The businessmodel is one where an organization defers to a third party to install, configure and operate an applicationon its behalf. The technology deployment pattern is to move the application from its traditional location inthe organization’s private data center to an instance hosted by the SaaS vendor and accessed by usersover the Internet.

SaaS is one form of “cloud computing,” the others being infrastructure as a service (IaaS) where organi-zations can add and remove virtual servers on a cloud service provider (CSP)’s network on demand andplatform as a service (PaaS) where organizations write and deploy applications using a CSP’s proprietaryapplication runtime environment. Examples of IaaS include Amazon EC2 and RackSpace.com. Exam-ples of PaaS include Force.com and Microsoft Azure. Examples of SaaS include Salesforce.com, GoogleApplications and WebEx.

Organizations may be motivated to move applications from a traditional model where software is installedon physical servers in a private data center to SaaS for a number of reasons, including:

1. Data center capacity – i.e., limited space, power or cooling capacity in their own data center.

2. Changing the cost structure from capital expense to operating expense (OpEx replaces CapEx).

3. Lower cost of operations, especially if demand is variable, by paying for utilization rather than capacity.

4. Lower cost due to more efficient operations at the SaaS provider than in the organization’s own ITorganization.

5. Access to application-specific expertise, which may lower deployment cost or risk and improve thevalue of the application.

4 Perimeter, firewalls and integrations

Unless an organization moves all of its systems and applications to SaaS and other “cloud” providers,communication between applications across firewalls must be considered.

Almost every organization has a private network, which is separated from the Internet by at least one fire-wall. Firewalls protect internal systems, which may have permissive configuration and may not be perfectlysecured, from being attacked from the public Internet. Essentially, firewalls reduce the set of possible usersand computers who can attack internal systems and applications to just authorized users and corporatecomputers.

The arrangement of on-premise and cloud-hosted infrastructure is illustrated in Figure 1.

To achieve this purpose, firewalls are generally relatively open in one direction and closed in the other. Inparticular, connections originating on the public Internet and destined for internal systems are generallyblocked, with only a few carefully chosen exceptions being allowed. For example, inbound connectionsto an organization’s public web site and mail gateway are allowed, as are virtual private network (VPN)connections by mobile users. All other connections – for example, to the organization’s internal mail servers,



OPEN

CLOSEDOff-siteuser

User atthe office

Firewall

Firewall

Firewall

SaaS application SaaS IAM Server

VPN Server

On-premiseapplication

Internet Private CorporateNetwork

Cloud ServiceProvider


Figure 1: Basic architecture including on-premise and cloud-hosted applications

file servers, applications, etc. are blocked. On the other hand, connections by users and systems insidethe corporate network to computers attached to the public Internet are often allowed. For example, a user’sweb browser, on the user’s desktop PC attached to the corporate network, can normally access public websites – directly or through a proxy.

Firewalls play an important role in any discussion of SaaS since they determine the direction in whichcommunication between applications can be established:

1. An IAM system attached directly to the corporate network can initiate connections to applications bothon the corporate network and on the Internet (i.e., SaaS applications).

2. An IAM system deployed in a SaaS model on the Internet cannot readily connect to systems andapplications on the private network:

(a) Some connections would require firewall rules to be added to allow inbound connections.

(b) Some connections would be very insecure – for example, they might contain plaintext passwords.

(c) Some connections are simply impossible, since they use a protocol that does not support for-warding by a firewall.

These three patterns of integration between a SaaS IAM system and on-premise applications areshown in Figure 2.

For these reasons, if an IAM system is deployed to a SaaS model, an additional component – a proxy serverused by the IAM system – must be deployed inside the corporate network. With a proxy server:



Application A

Application B

Application C

c Impossible toforward protocol

b Insecureinboundprotocol

a Firewall rulefor inboundconnection

InternetFirewall

Private CorporateNetwork

Firewall

IAM server

SaaS IAMCloud Service

Provider

Figure 2: Integrations between SaaS IAM systems and on-premise applications

1. It is possible to eliminate special firewall rules by having the proxy server initiate periodic connectionsto the IAM system, asking for tasks to complete.

2. Alternately, a single firewall rule can be added, allowing the SaaS IAM system to initiate connectionsto the proxy server, and only to the proxy server.

3. The proxy server communicates with internal systems and applications on behalf of the IAM system,possibly using communication protocols that are insecure or that cannot be forwarded by the firewall.

4. Communication between the IAM system and the proxy server can be designed to be both efficientand secure. This is important because the Internet is not a trusted environment and because con-nections over the Internet are typically much slower (lower bandwidth, higher latency) than inside thecorporate network.

Integration with on-premise applications using an on-premise IAM proxy server is illustrated in Figure 3.

While a proxy server is mandatory in almost every IAM/SaaS deployment, it does have a drawback, whichis that an additional physical or virtual server is required – inside the perimeter. This goes against one of thecore value propositions of SaaS – namely, to reduce the number of on-premise servers and applications.This drawback can be mitigated by using a virtual rather than physical server and by minimizing the config-uration and complexity required on this server – moving as much “intelligence” as possible to the SaaS IAMsystem.



Application A Application B Application C

Variouslocal protocols

Forward a singleTCP/IP port

IAM server

InternetSaaS IAMCSP Firewall

Private CorporateNetworkFirewall

Secure, efficientforwarder-friendlyprotocol

IAM proxyserver

c Accessible toproxy

b Limit pathof vulnerableprotocol

a Only opensingle port -not one per app

Figure 3: Integrations between with on-premise applications through an on-premise proxy server

5 Risk assessment – identity data hosted by a third party

One of the most common objections to moving identity and access management systems from an on-premise to a cloud-hosted model is questions about the security of sensitive data.

IAM systems typically contain privacy-sensitive data, ranging from social security numbers and dates ofbirth to home address information. Moving this data to premises and systems hosted by a third party raisesquestions about how securely the data will be managed.

In practice, SaaS vendors cannot afford security compromises, since just one compromise could cause theircustomers to flee and their business to fail. Because of the risk of such an outcome, any SaaS vendor witha serious, long-term business plan can be reasonably expected to make robust investments in informationsecurity technology and processes.

Organizations should verify that their SaaS vendor is taking proper care by asking about their perimeterdefense, patch management, host and network intrusion prevention and intrusion detection systems, virusscanners, access control policies and so on. Any SaaS vendor, but especially an IAM SaaS vendor thatcannot provide a clear, transparent and credible description of their security posture should be disqualified.

Once operational security has been addressed, the remaining question is one of liability. Organizationsface serious legal and financial consequences as a result of compromise to the privacy of their employees,contractors or customers. To mediate this risk, organizations can and do purchase insurance policies toprotect them in the event of a compromise. When considering an IAM SaaS solution, organizations shouldtherefore consider:

1. Is legal liability in the event of a privacy-compromising security incident transferred to the IAM SaaS



vendor?

2. Does the organization’s insurance policy cover security incidents that happened at the IAM SaaSvendor that impact the organization’s data?

3. Does the IAM SaaS vendor have a comparable insurance policy and would its coverage protect theorganization?

In short, risk management, transfer of legal liability and insurance should all be considered.

6 One identity administration system or two?

Given the need for a proxy inside the corporate network’s perimeter, one might consider two separate IAMsystems – one for managing users and entitlements inside the perimeter and another for managing usersand entitlements on SaaS-hosted applications.

While this approach might have some technical appeal, it makes no sense from the perspective of businessprocess. The whole point of IAM systems is to move the administration of users, authentication factors,identity information and security entitlements from the silos of individual applications into a shared infras-tructure. An employee is only hired once – not once for internal systems and again for SaaS applications.A contractor is deactivated once, not once per data center.

In short, organizations should deploy a single IAM system and it should manage users and entitlementswherever they happen to be – on-premise or “in the cloud.”

7 Federating authentication and authorization

To minimize the proliferation of IDs and passwords, some organizations are deploying a federated accessmanagement system. These systems generally allow users to authenticate against their corporate directoryand access a SaaS application without having to sign on again.

Federated access management systems leverage two components:

1. An identity provider (IdP) – which authenticates the user and issues assertions about the user’sidentity and authentication status.

2. A service provider (SP) – which may be part of or integrated with an application that users will signinto. This is the part that accepts assertions about the user’s identity and authentication status.

These two components may either request information about or make assertions about users. They usuallycommunicate through the user’s web browser - which is normally the only component able to contact both.

When considering federation, it is helpful to think about where the user, directory, identity provider andapplication/service provider are installed in relation to the corporate network and whether the user is signinginto the application from a device capable of authenticating against the corporate directory:



1. If the user wishes to sign into a federated application from inside the corporate network, using anendpoint device that normally does bind to the corporate directory (e.g., that has a Kerberos ticketissued by an Active Directory domain controller) then single sign-on to the IdP is possible, especiallyif the IdP is also inside the corporate perimeter and can itself communicate with a domain controller.

This basic federation scenario is illustrated in Figure 4.

2. If the user wishes to sign into a federated application from outside the corporate network, using aWindows PC and a VPN connection, then for all practical purposes this is the same scenario asabove.

3. If the user wishes to sign into a federated application from outside the corporate network perimeter orusing a device such as a mobile phone, which does not authenticate to the corporate directory, then:

(a) The IdP will have to prompt the user to sign in with an ID and password or some other credentials.

(b) If the IdP is itself outside the corporate network, using a SaaS service delivery model, then theIdP needs a mechanism to connect to a directory service inside the corporate network to validatethose credentials.

The infrastructure required to enable users from outside the corporate network or VPN, or using non-corporate devices to sign into a federated application is illustrated in Figure 5.

CorporateDirectory

Application

User

SPIdP

1 Primaryauthentication 7 Logged on

6 Provide ID

5 Provide ID4 Request ID

2 Applicationaccess

3RequestID

Figure 4: Sequence of messages for federated login to an application by an on-premise user



User -mobilelaptop

DirectoryServer

ProxyforDirectory

SaaSApplication

FederatedIdP


User -smartphone

Firewall

Internet

CSP

CSP

Figure 5: Infrastructure required for users to sign into a federated IdP without a corporate PC

8 Securing privileged accounts

There are at least three scenarios where cloud computing and SaaS in particular relate closely to systemsthat manage access to privileged accounts:

8.1 Securing access to cloud computing infrastructure

Organizations that invest in SaaS, PaaS or IaaS infrastructure must manage administrative login IDs oncloud-hosted systems. These login IDs must be secured, even more urgently than internal administrativeIDs, since they access systems not protected by a perimeter defense.

It follows that organizations that invest in cloud computing need a privileged access management system tosecure access to their Internet-attached infrastructure. This can either be an on-premise or a cloud-hostedsystem.

Use of a privileged access management system to secure access to privileged accounts on cloud-hostedsystems is illustrated in Figure 6.

8.2 Leveraging cloud infrastructure for credential vault replication

Most privileged access management systems work by randomizing the passwords to privileged accounts.These passwords are encrypted and stored in a vault. To protect against data loss, the vault should alwaysbe replicated and preferably across two or more data centers.

Organizations with just a single data center can deploy a replica vault on an IaaS cloud service provider’s



PrivilegedAccessManager


FirewallPublic

Internet

CSP

CSP

CSP

SaaS app

IaaS VM

IaaS VMIaaS VM

PaaS app

PasswordVault

Figure 6: Controlling access to privileged accounts on cloud infrastructure

network, to get multi-site replication.

Organizations may also opt to host the entire privileged access management system on a SaaS or IaaSprovider’s network, with just proxy servers inside their network to provide connectivity to on-premise systemsand applications.

Replication of the credential vault to a cloud-hosted server is illustrated in Figure 7.

PrivilegedAccessManager

BackupPrivilegedAccessManager


Firewall PublicInternet


Managed System

PasswordVault

ReplicaPasswordVault

Figure 7: Replicating a credential vault to a cloud-hosted server

8.3 Connecting cloud-hosted applications to on-premise systems

Organizations may deploy SaaS applications which need credentials to internal systems to initiate a varietyof integrations. For example, a security scanner from a SaaS vendor such as Qualys must use an on-premise appliance which performs the actual scans on the private network.

This business model calls for the SaaS application to have access to credentials which are used to connectto on-premise systems. Placing these sensitive credentials at the SaaS provider’s facility creates an ele-



vated risk profile for the SaaS vendor, as they wind up in possession of multiple organizations’ credentials.This makes them an attractive target for security attacks.

A better model is to host a privileged access management system – either on-premise or SaaS – separatelyfrom the SaaS application which needs credentials to on-premise systems. The on-premise appliance whichinitiates connections to private systems and applications then fetches credentials from this vault on-demand,eliminating the need for the original SaaS application to have these credentials.

Enabling a SaaS application to integrate with on-premises applications without having direct access to thoseapplications’ credentials is illustrated in Figure 8.


Firewall Internet CSP

SaaS App

IntegratedApplicationPassword

VaultPrivilegedAccessManager

SaaS ProxyAppliance

Request

Credential

Connect

Figure 8: Providing credentials to a SaaS application’s on-premise proxy appliance

9 Multi-tenancy and standardized business processes

IAM systems contain extensive configuration data:

1. Address information and login credentials for integrations:

(a) Target systems where users, entitlements, identity profiles and authentication factors are man-aged.

(b) Incident management systems where tickets are created and updated.

(c) Service catalogs which may initiate change requests.

(d) E-mail systems used to invite users to act and notify users of events.

(e) Security incident event management (SIEM) systems, which aggregate event logs.

(f) Systems management infrastructure, used to monitor the health of all systems, including IAM.

2. Business logic and policies, including:

(a) How to compose new login IDs.

(b) How to match existing accounts to user profiles.

(c) Mapping identity attributes to target systems.

(d) Which groups to manage on each system.



(e) Role definitions and assignment rules.

(f) Segregation of duties policies.

(g) Auto-provisioning logic that reacts to changes detected on systems of record.

(h) Routing rules to select authorizers for changes.

(i) Rules for sending reminders to non-responsive authorizers.

(j) Rules for escalating away from non-responsive authorizers to their alternates.

The efficiency of an IAM service provider’s delivery model and the price customers must pay for the serviceboth improve with standardization. For example, if all customers use the same change authorization work-flow logic, then these this logic can be written once and the cost of developing and maintaining the relevantrules can be shared by multiple customers.

This model, where efficiency increases as more of the IAM system’s configuration is shared between cus-tomers, applies to every part of IAM system configuration. For example, if all customers can be assumedto use the same integrations – for example, Active Directory, Exchange and Windows file servers – thenthe cost of developing robust integrations with these systems is shared by all customers, leading to a muchlower per-customer cost.

The conclusion here is that IAM-as-a-service includes a strong incentive to standardize business processesand integrations, as this substantially lowers service delivery costs. Organizations should seriously consideradopting standardized, best-practices processes, as this can both enhance their change management pro-cesses and lower the cost of the IAM system.

10 Identity management deployment patterns

Given that standardized business processes are cost effective, the next question is: what kinds of organi-zations can share a set of consistent business processes? It is unlikely a single set of business processeswill apply to every organization, across private and public sectors, industry verticals, countries and cultures.

In practice, there are at least three business models that relate to IAM system deployment, each of whichcan be standardized and applied to a broad range of organizations. These are:

10.1 Corporate model

This model applies to corporations, government entities, military entities, hospitals, non-profits and facultyand staff in higher education institutions. What these organizations have in common is:

1. Scale: typically 1,000 to 300,000 users.

2. Relationship: users are normally employees or contractors. Users are generally hired and paid by theorganization.

3. Infrastructure: normally use Active Directory, provide e-mail and file services and run a variety ofapplications.



4. Perimeter: the organization operates a private network with a defined perimeter, including firewalldefenses.

5. Staff turn-over: typically gradual over time, rather than in large bursts.

6. Endpoint devices: the organization typically provides desktop or laptop computers, desks, chairs,phones, etc. to users.

Corporations and similar organizations need to automate onboarding, transfers, profile updates, entitlementmanagement and termination processes for their internal users.

10.2 Higher education model

A separate model is needed to manage the identities and entitlements of students and alumni in universitiesand colleges:

1. Scale: typically 1,000 – 100,000 students; 10,000 – 1,000,000 alumni. The number of alumni isalways growing.

2. Relationship: students enroll, stay for one or more semesters and either leave prematurely or becomealumni. There is usually no practical, scalable way to determine when an alumni has died, so thenumber of alumni only grows.

3. Infrastructure: normally an LDAP directory. E-mail may be provided by an on-premise system oroffloaded to a provider such as Google or Microsoft. Users may have home directories and loginson Windows or Unix/Linux systems. Most organizations also operate specialty applications for courseenrollment, library access and cross-institution federation.

4. Perimeter: while a private network exists, access to on-premise systems from the Internet is oftenvery open.

5. User turn-over: large batches of onboarding and deactivation when semesters begin and end.

6. Endpoint devices: a combination of fixed assets (e.g., labs) and personal devices (e.g., user-ownedlaptops and home PCs). No central device management.

Colleges and universities provide relatively minimal IT services to each user but must enroll and deactivatelarge numbers of users at a time.

10.3 Internet portal model

Many organizations maintain external portals in addition to internal identities. For example, a corporationmay operate a web portal for e-Commerce, financial services or customer support. A government entitymay maintain a portal for citizen access to e-Government services. These externally-facing portals needtheir own directory and their own change management processes, which are normally distinct from thoseused to manage internal users and entitlements.

1. Scale: typically 100,000 to millions of users.



2. Relationship: In some cases, new users may have no prior or documented relationship with the or-ganization (e.g., e-commerce). In other cases, new users may have a prior relationship with theorganization that needs to be considered when creating a portal account. In general, users are notemployed by the operator of the web portal, but may purchase goods or receive services from it.

3. Infrastructure: normally an LDAP directory which authenticates users into one or more Internet-facingapplications.

4. Perimeter: applications are accessible from the Internet, so any firewalls are simply to protect compo-nents of the system.

5. User turn-over: large number of registrations, which may be initially anonymous. Users rarely volun-teer to deactivate their accounts and there may be no system of record which identifies users whoshould be removed.

6. Endpoint devices: personal or public user devices, ranging from PCs to phones.

Internet portals provide relatively minimal IT services to large numbers of users, who may self-enroll at anytime.

11 Summary

There is no technical barrier to moving IAM systems from an on-premise delivery model to a SaaS model.That said, organizations should carefully consider:

1. Connectivity to on-premise applications, which almost inevitably depends on an on-premise proxyserver.

2. Standardization of business processes, as the ability to spread process implementation costs acrossmultiple customers is the main source of operational efficiency for the IAM/SaaS vendor.

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: [email protected]

File: / pub/ wp/ documents/ iam-saas/ iam-saas-howto-3.texDate: 2011-08-02

http://Hitachi-ID.com/

identity management as a service: deploying iam in a saas model

Technology

service iam saas

saas model

service saas provider

access management system

examples of saas

background saas software

background iam identity

saas vendor