From: Securosis Highlights – Understanding Identity Management for Cloud Service: The Solution Space

Posted on 2013/01/07

a quick re-post from Securosis Highlights

Understanding Identity Management for Cloud Service: The Solution Space by (author unknown)

Adrian and Gunnar here: After spending a few weeks getting updates from Identity and Access Management (IAM) service vendors – as well as a couple weeks for winter break – we’ve gathered the research necessary to delve into the meat of our series on Understanding and Selecting Identity Management for Cloud Services. In case you missed our introductory post](, we outlined the topics we will cover in this research project. This series is intended as the market overview, taking a broad look at issues you need to consider when evaluating cloud-based identity support systems. And while we hinted at the reasons why cloud computing models force a change in in how we approach access controls, in today’s post we’ll more fully flesh out the problems cloud IAM.

The Cloud excels at providing enterprise with apps and data. But what about identity information? Companies face issues trying to retain control of identity management while getting the benefits of the cloud. The goal is to unify identity management for internal and external user across both traditional IT and 3rd party cloud services.

It is possible to manage user access to cloud computing resources in-house, but the architecture must cope with issues of integration complexity, and management costs. Most, and especially enterprises, find these inconveniences outweigh the benefits. For many of the same reasons companies adopt cloud computing services instead of in-house services (e.g.: on-demand service, elasticity, broad network access, reduction in CAPX expenditures, total cost) companies are also leveraging third party cloud services to manage identity and access management.

Managing identity was a lot simpler when the client-server computing model was the norm, as each user was limited to their desktop PC, and another set of credentials to access a handful of servers – setup the ACLs, sprinkle on some Roles and voila! However, as servers and applications multiplied, the ‘end point’ morphed from the desktop to remote users, and servers were integrated to other server domains – never mind ACLs and Roles, what realm are we in? – we used directory services to provide a single identity management repository, and help propagate identity across the enterprise. Now, we have an explosion of external service providers; financial applications, cloud storage, social media, workflow, CRM, email, collaboration and web conferencing just to name a few. These extra-enterprise services are considered business critical, but don’t directly link with traditional directory services.

Cloud computing services turn identity management on its ear. The big shift is not just that IT no longer owns the servers or the applications they rely upon, or that the providers capabilities are not fully compatible with existing internal systems, but also the change in how users consume cloud services. In fact, an employee may consume cloud services – provided by their company – without ever touching in-house IT systems. Just about every enterprise uses Software as a Service (SaaS), and many use Platform and Infrastructure as a Service options (PaaS and IaaS respectively) as well, each using a different approaches to Identity and Access Management. Extending traditional corporate identity services outside the corporate environment is not a trivial effort. It requires integration of existing IAM systems with the cloud service provider. And most companies are reliant on dozens of cloud service providers, each with a different set of identity and authorization capabilities, as well as different programatic and web interfaces. The time, effort and cost to develop – and maintain – links with each service provider is overwhelming.

Cloud Identity Solutions

Ideally we want to extend the existing in-house identity management capabilities to 3rd party systems, minimizing the work for IT management while delivering services to end users with a minimum of disruption. And we’d like to maintain control over user access, adding and removing users as needed, propagating new authorization policies without significant latency. We also want to collect information on access and policy status that helps meet security and compliance requirements. And rather than build a custom bridge to each and every third party service, we’d like to have a simple management interface that extends our controls and policies to the various third party services.

The common list of features and benefits provided by cloud identity and access management systems:

  • Authentication, Single Sign-on (SSO): One of the core services is the ability to authenticate users based upon provided credentials, and then allow that user to access multiple – internal and external – services without having to repeatedly supply credentials to each service they use. Offering SSO to users is, of course, just about the only time anyone is happy to see the security team show up – make the most of it!
  • Identity Federation: Federated identity is where identity and authorization settings are collected from multiple identity management systems, allowing for different systems to define user capabilities and access. Identity and authorization are a shared responsibility across multiple authoritative sources. Federated identity is a super-set of authentication and single sign-on. Federation made headway as a conveyance engine for SSO and Web Services. Its uptake in cloud has been substantial since its core architecture helps companies navigate one of the thornier cloud issues – retaining in house control of user accounts whilst leveraging cloud apps and data.
  • Granular authorization controls: Access is typically not an ‘all-or-nothing’ proposition, rather each user is allowed access to a subset of functions and data stored in the cloud. Authorization maps are what instruct an application on which resources it provides to a user. To what degree you can tune a users access will depend both on the capabilities of the cloud service provider as well as the capabilities of the IAM system. The main industry trends in authorization in general and the cloud specifically are focuses on finer grained access control and to the extent practical removing access policy from code. In a nutshell, roles are necessary but not sufficient for authorization, you need attributes too. You also do not want to spelunk through millions of lines of code to define/review/change/audit them, you would like them configurable and data driven.
  • Administration: Ideally user administrators would like a single management pane for administering users and managing identity across multiple services. The goal of most cloud IAM systems is to do just that, but they need to offer granular adjustments to authorization across different applications while still pulling data from different authoritative sources on identity.
  • Integration with internal directory services: Cloud IAM systems rely on integration with in-house LDAP, Active Directory, HR systems and other services in order to replicate existing employee identity, roles and groups into cloud services. The in-house IAM services remain central authority for in-house identity, but delegate responsibility for cloud access management to the cloud IAM service. This integration reduces set-up efforts and AD, Audit/logging)
  • Integration with external services: One of the core benefits of a cloud IAM provider is they offer connectors to common cloud services so you don’t need to write your own integration code. For example, the procedural interface to communicate with Salesforce is different than the ???what did you mean here??? . Offering pre-built connections to common SaaS, PaaS, and IaaS vendors, integration with new services is both easier and faster.

Additional capabilities may include multi-factor authentication support, mobile user integration, support for multiple user personas, and the ability to activity to specific users. These features help tie traditional identity management to cloud services. However, as vendors attempt to solve these issues, cloud IAM creates several new problems that don’t get the same degree of attention.

  • API’s: While IAM vendors offer connectors to the most common cloud services, it’s likely they will not provide all of the connectors you need. You’ll either need to provide your own integration, or contract with your IAM vendor to build the custom connector on your behalf. There is the additional challenge here of onboarding 3rd party developers and giving them limited access rights.
  • Authorization Mapping: How you specify authorization rules (i.e. role vs. attribute) in different ways. It may not be feasible to specify the your existing access rules with the cloud service provider, at least not without a great deal of wok.
  • Audit: In-house systems can be linked with log management and SIEM systems to produce compliance reports and provide monitoring and detection of security related events. Audit logs from cloud service providers remains problematic as most, given the multi-tenant nature of the service, cannot provide logs without disclosing data from other tenants.
  • Privacy: Users, user attributes and other information is being pushed outside of your corporate network and into one or more cloud data repositories. The security and privacy controls provided are not fully under your control, and you will need to explore what your vendor does and does not provide.
  • Latency: Propagating rule changes from internal IAM to cloud IAM make take some time. For example, if an employee is terminated or has their access rights reduced, there may be a lag between the internal rule change and when the cloud service enforces the change. Latency is a subject to discuss with both your IAM provider and cloud service provider.
  • Privileged User Management: This has been a problem for a long time, and the cloud adds a new wrinkle. In the past the privileged users worked for you. If things went pear shaped, you can handle this as an HR event. With cloud not so much.
  • App Identity: Once you have the user logged in, you may still need to verify the app they are using, or maybe there is no user at all, just middleware. But where did the request come from? The answer for many apps today is that as long as you know how to call the service they do not verify the client in any kind of even medium strength authentication. As with the previous point, this has been a problem in IT for a long time.
  • Mobile: Security teams are still absorbing the changes of the cloud, but technology does not wait around, we have a whole new paradigm to tool up for. The reason Mobile is relevant for Cloud is that the clients are very likely to be mobile. Oh, and it means there is yet another account and domain to manage.

In our next post we’ll discuss how IAM services are built into the infrastructure of the different cloud service models (SaaS, PaaS, and IaaS), the common communication protocols and discuss the different conceptual approaches.

– Adrian Lane
(0) Comments
Subscribe to our daily email digest

Posted in: reading