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.

Contents
1 Introduction 1
2 Background - IAM 1
3 Background - SaaS 2
4 Perimeter, ﬁrewalls 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) using
a software as a service (SaaS) provider. It identifies business and technical challenges that arise when an
IAM system is moved outside of an organization’s private network perimeter and offers solutions to address
them.
Every medium to large organization can benefit from an IAM system. Many organizations are interested in
moving some of their IT infrastructure from private data centers to “the cloud” – which often is short-hand
for software as a service (SaaS). It follows that many organizations will be interested in moving their existing
IAM 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 engines
and more.
This document’s primary focus is on systems that create, manage and deactivate the access of internal
users to systems and applications in medium to large organizations (1,000 to 300,000 users). This includes
user provisioning, access certification, password management and single sign-on applications designed for
deployments 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 depend
on 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 call
volume) 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 business
model is one where an organization defers to a third party to install, configure and operate an application
on its behalf. The technology deployment pattern is to move the application from its traditional location in
the organization’s private data center to an instance hosted by the SaaS vendor and accessed by users
over 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 and
platform as a service (PaaS) where organizations write and deploy applications using a CSP’s proprietary
application 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, Google
Applications and WebEx.
Organizations may be motivated to move applications from a traditional model where software is installed
on 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 IT
organization.
5. Access to application-specific expertise, which may lower deployment cost or risk and improve the
value 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 perfectly
secured, from being attacked from the public Internet. Essentially, firewalls reduce the set of possible users
and computers who can attack internal systems and applications to just authorized users and corporate
computers.
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. In
particular, connections originating on the public Internet and destined for internal systems are generally
blocked, with only a few carefully chosen exceptions being allowed. For example, inbound connections
to 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
CLOSED
Off-site
user
User at
the office
Firewall
Firewall
Firewall
SaaS application SaaS IAM Server
VPN Server
On-premise
application
Internet Private Corporate
Network
Cloud Service
Provider
Cloud Service
Provider

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 inside
the corporate network to computers attached to the public Internet are often allowed. For example, a user’s
web browser, on the user’s desktop PC attached to the corporate network, can normally access public web
sites – directly or through a proxy.
Firewalls play an important role in any discussion of SaaS since they determine the direction in which
communication between applications can be established:
1. An IAM system attached directly to the corporate network can initiate connections to applications both
on 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 and
applications 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 are
shown in Figure 2.
For these reasons, if an IAM system is deployed to a SaaS model, an additional component – a proxy server
used by the IAM system – must be deployed inside the corporate network. With a proxy server:

Application A
Application B
Application C
c Impossible to
forward protocol
b Insecure
inbound
protocol
a Firewall rule
for inbound
connection

Internet
Firewall
Private Corporate
Network
Firewall
IAM server
SaaS IAM
Cloud 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 connections
to the IAM system, asking for tasks to complete.
2. Alternately, a single firewall rule can be added, allowing the SaaS IAM system to initiate connections
to 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 efficient
and 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 the
corporate 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, which
is that an additional physical or virtual server is required – inside the perimeter. This goes against one of the
core 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 IAM
system.

Application A Application B Application C
Various
local protocols
Forward a single
TCP/IP port
IAM server
InternetSaaS IAM
CSP Firewall
Private Corporate
NetworkFirewall
Secure, efficient
forwarder-friendly
protocol
IAM proxy
server
c Accessible to
proxy
b Limit path
of vulnerable
protocol
a Only open
single 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 of
birth to home address information. Moving this data to premises and systems hosted by a third party raises
questions about how securely the data will be managed.
In practice, SaaS vendors cannot afford security compromises, since just one compromise could cause their
customers to flee and their business to fail. Because of the risk of such an outcome, any SaaS vendor with
a serious, long-term business plan can be reasonably expected to make robust investments in information
security technology and processes.
Organizations should verify that their SaaS vendor is taking proper care by asking about their perimeter
defense, patch management, host and network intrusion prevention and intrusion detection systems, virus
scanners, access control policies and so on. Any SaaS vendor, but especially an IAM SaaS vendor that
cannot 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. Organizations
face 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 to
protect them in the event of a compromise. When considering an IAM SaaS solution, organizations should
therefore 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 SaaS
vendor that impact the organization’s data?
3. Does the IAM SaaS vendor have a comparable insurance policy and would its coverage protect the
organization?
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 IAM
systems – one for managing users and entitlements inside the perimeter and another for managing users
and entitlements on SaaS-hosted applications.
While this approach might have some technical appeal, it makes no sense from the perspective of business
process. 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 entitlements
wherever 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 access
management system. These systems generally allow users to authenticate against their corporate directory
and 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’s
identity and authentication status.
2. A service provider (SP) – which may be part of or integrated with an application that users will sign
into. 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 usually
communicate 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 and
application/service provider are installed in relation to the corporate network and whether the user is signing
into 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 an
endpoint device that normally does bind to the corporate directory (e.g., that has a Kerberos ticket
issued by an Active Directory domain controller) then single sign-on to the IdP is possible, especially
if 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 a
Windows PC and a VPN connection, then for all practical purposes this is the same scenario as
above.
3. If the user wishes to sign into a federated application from outside the corporate network perimeter or
using 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 the
IdP needs a mechanism to connect to a directory service inside the corporate network to validate
those 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.
Corporate
Directory
Application
User
SPIdP
1 Primary
authentication 7 Logged on
6 Provide ID
5 Provide ID
4 Request ID
2 Application
access
3
Request
ID
Figure 4: Sequence of messages for federated login to an application by an on-premise user

User -
mobile
laptop
Directory
Server
Proxy
for
Directory
SaaS
Application
Federated
IdP
Private Corporate
Network
User -
smart
phone
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 systems
that 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 on
cloud-hosted systems. These login IDs must be secured, even more urgently than internal administrative
IDs, 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 to
secure access to their Internet-attached infrastructure. This can either be an on-premise or a cloud-hosted
system.
Use of a privileged access management system to secure access to privileged accounts on cloud-hosted
systems 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 always
be 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

Privileged
Access
Manager
Private Corporate
Network
Firewall
Public
Internet
CSP
CSP
CSP
SaaS app
IaaS VM
IaaS VM
IaaS VM
PaaS app
Password
Vault
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 IaaS
provider’s network, with just proxy servers inside their network to provide connectivity to on-premise systems
and applications.
Replication of the credential vault to a cloud-hosted server is illustrated in Figure 7.
Privileged
Access
Manager
Backup
Privileged
Access
Manager
Private Corporate
Network
Firewall Public
Internet
Cloud Service
Provider
Managed
System
Password
Vault
Replica
Password
Vault
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 variety
of 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 connect
to 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 – separately
from the SaaS application which needs credentials to on-premise systems. The on-premise appliance which
initiates 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 those
applications’ credentials is illustrated in Figure 8.
Private Corporate
Network
Firewall Internet CSP
SaaS
App
Integrated
ApplicationPassword
Vault
Privileged
Access
Manager
SaaS
Proxy
Appliance
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 service
both 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 relevant
rules 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 assumed
to use the same integrations – for example, Active Directory, Exchange and Windows file servers – then
the cost of developing robust integrations with these systems is shared by all customers, leading to a much
lower per-customer cost.
The conclusion here is that IAM-as-a-service includes a strong incentive to standardize business processes
and integrations, as this substantially lowers service delivery costs. Organizations should seriously consider
adopting 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 processes
will 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 which
can 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 faculty
and 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 the
organization.
3. Infrastructure: normally use Active Directory, provide e-mail and file services and run a variety of
applications.

4. Perimeter: the organization operates a private network with a defined perimeter, including firewall
defenses.
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, entitlement
management 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 universities
and colleges:
1. Scale: typically 1,000 – 100,000 students; 10,000 – 1,000,000 alumni. The number of alumni is
always growing.
2. Relationship: students enroll, stay for one or more semesters and either leave prematurely or become
alumni. There is usually no practical, scalable way to determine when an alumni has died, so the
number of alumni only grows.
3. Infrastructure: normally an LDAP directory. E-mail may be provided by an on-premise system or
offloaded to a provider such as Google or Microsoft. Users may have home directories and logins
on Windows or Unix/Linux systems. Most organizations also operate specialty applications for course
enrollment, library access and cross-institution federation.
4. Perimeter: while a private network exists, access to on-premise systems from the Internet is often
very 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-owned
laptops and home PCs). No central device management.
Colleges and universities provide relatively minimal IT services to each user but must enroll and deactivate
large numbers of users at a time.
10.3 Internet portal model
Many organizations maintain external portals in addition to internal identities. For example, a corporation
may operate a web portal for e-Commerce, financial services or customer support. A government entity
may maintain a portal for citizen access to e-Government services. These externally-facing portals need
their own directory and their own change management processes, which are normally distinct from those
used 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 the
organization that needs to be considered when creating a portal account. In general, users are not
employed 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-facing
applications.
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 who
should 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 any
time.
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 proxy
server.
2. Standardization of business processes, as the ability to spread process implementation costs across
multiple 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: sales@Hitachi-ID.com
File: / pub/ wp/ documents/ iam-saas/ iam-saas-howto-3.tex
Date: 2011-08-02

Identity Management as a Service: Deploying IAM in a SaaS Model

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (11)

Mais de Hitachi ID Systems, Inc.

Mais de Hitachi ID Systems, Inc. (20)

Último

Último (20)

Identity Management as a Service: Deploying IAM in a SaaS Model