Identity Management as a Service: Deploying IAM in a SaaS Model
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

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

  • 2,546 views
Uploaded on

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......

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.

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,546
On Slideshare
2,546
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
127
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Identity Management as a Service Deploying IAM in a SaaS Model © 2014 Hitachi ID Systems, Inc. All rights reserved.
  • 2. 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
  • 3. 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
  • 4. Identity Management as a Service (IAM SaaS) 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, © 2014 Hitachi ID Systems, Inc.. All rights reserved. 2
  • 5. Identity Management as a Service (IAM SaaS) 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: © 2014 Hitachi ID Systems, Inc.. All rights reserved. 3
  • 6. Identity Management as a Service (IAM SaaS) 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 4
  • 7. Identity Management as a Service (IAM SaaS) 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 © 2014 Hitachi ID Systems, Inc.. All rights reserved. 5
  • 8. Identity Management as a Service (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: © 2014 Hitachi ID Systems, Inc.. All rights reserved. 6
  • 9. Identity Management as a Service (IAM SaaS) 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 © 2014 Hitachi ID Systems, Inc.. All rights reserved. 7
  • 10. Identity Management as a Service (IAM SaaS) 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 © 2014 Hitachi ID Systems, Inc.. All rights reserved. 8
  • 11. Identity Management as a Service (IAM SaaS) 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- © 2014 Hitachi ID Systems, Inc.. All rights reserved. 9
  • 12. Identity Management as a Service (IAM SaaS) 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 10
  • 13. Identity Management as a Service (IAM SaaS) (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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 11
  • 14. Identity Management as a Service (IAM SaaS) 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 12
  • 15. Identity Management as a Service (IAM SaaS) 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