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 have gathered the research we need to delve into the meat of our series on Understanding and Selecting Identity Management for Cloud Services. Our introductory post outlined the topics we will cover. This series is intended as a market overview, taking a broad look at issues you need to consider when evaluating cloud-based identity support systems. The intro hinted at the reasons cloud computing models force change in our approaches to access control, but today’s post will flesh out the problems of 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 taking advantage of the cloud. The goal is to unify identity management for internal and external user across both traditional IT and third party cloud services.

It is possible to manage user access to cloud computing resources in-house, but the architecture must address take integration complexity and management costs into account. Most organizations – particularly enterprises – find these inconveniences outweigh the benefits. For many of the same reasons (including on-demand service, elasticity, broad network access, reduction in capital expenditures, and total cost) companies adopt cloud computing services instead of in-house services, and they also leverage 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, and users were mostly limited to a desktop PC with another set of credentials to access a handful of servers.. set up the ACLs, sprinkle on some roles, and voila! But as servers and applications multiplied, the “endpoint” shifted from fixed desktop to remote devices, 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, to name a few. These ‘extra-enterprise’ services are business critical, but don’t directly link into traditional directory services.

Cloud computing services turn identity management on its ear. The big shift comes in three main parts: IT no longer owns the servers and applications the organization relies upon, provider capabilities are not fully compatible with existing internal systems, and the ways users consume cloud services have changed radically. In fact an employee may consume corporate cloud services 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 (PaaS and IaaS, respectively) as well – each with its own 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(s). Most companies rely 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 can be overwhelming.

Cloud Identity Solutions

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

Features and benefits common to most cloud identity and access management systems include:

• Authentication, Single Sign-on (SSO): One of the core services is the ability to authenticate users based on provided credentials, and then allow each user to access multiple (internal and external) services without having to repeatedly supply credentials to each service. 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, enabling different systems to define user capabilities and access. Identity and authorization are a shared responsibility across multiple authoritative sources. Federated identity is a superset 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 because its core architecture helps companies navigate one of the thornier cloud issues: retaining in-house control of user accounts while leveraging cloud apps and data.
• Granular authorization controls: Access is typically not an ‘all-or-nothing’ proposition – each user is allowed access to a subset of functions and data stored in the cloud. Authorization maps instruct applications which resources to provide to each user. How much control you have over each user’s access depends, both on the capabilities of the cloud service provider and on the capabilities of the IAM system. The larger industry trends – in authorization in general and the cloud specifically – are a focus on finer-grained access control, and removing access policy from code as much as possible. 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, so they should be configurable and data driven.
• Administration: User administrators generally prefer 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 identity authorities.
• Integration with internal directory services: Cloud IAM systems rely on integration with in-house LDAP, Active Directory, HR systems, and other services to replicate existing employee identity, roles, and groups into cloud services. In-house IAM services remain the central authority for in-house identity, but delegate responsibility for cloud access management to the cloud IAM service.
• 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, and support for multiple user personas. These features help tie traditional identity management into cloud services. But as vendors attempt to solve these issues, cloud IAM creates several new problems that don’t get the same degree of attention.

• APIs: While IAM vendors offer connectors to the most common cloud services, they are unlikely to provide all the connectors you need. You will probably to either provide your own integration or contract with your IAM vendor to build a custom connector. This raises the additional challenge of onboarding third party developers and giving them limited access rights.
• Authorization Mapping: There are many possible ways to specify authorization rules, such as by role vs. by attribute. Your existing access rules may need to be rewritten for a cloud service provider.
• 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 – their multi-tenant models prevent most from providing full logs, because the logs would necessarily disclose data on other customers.
• Privacy: Users, user attributes, and other information are pushed outside your corporate network and into one or more cloud data repositories. The security and privacy controls for the external repositories are not fully under your control, so you need to explore what your vendor does and does not provide.
• Latency: Propagating rule changes from internal IAM to cloud IAM can 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. Historically the privileged users were all employees, and if things went pear-shaped you can handle it as an HR event. With the cloud, that breaks down.
• App Identity: Once you have the user logged in, you may still need to verify the application 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 – even with medium-strength authentication. Like the previous point, this has been an IT problem for a long time.
• Mobile: Security teams are still absorbing the implications of the cloud, but technology does not wait around – we have a whole new paradigm to tool up for. Mobile is particularly relevant for the cloud because cloud clients are very likely to be mobile. Oh, and that means yet another account system and domain to manage.

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