This post will discuss the architecture and deployment models for identity and access management for cloud services. This is obviously complex – we are covering three different cloud service models (SaaS, PaaS, & IaaS); in three different deployment options (public, private, & hybrid); with a variety of communication protocols to address authentication, authorization, and provisioning. The Cloud Security Alliance has cataloged many different identity ‘standards’, but the fact that we have dozens of standards to choose from illustrates how unresolved this whole field is. Worse, each cloud provider’s standards support is likely to vary (incompatibly) from others in the field – so you will likely need custom code to connect and share identity information.

The point is that discussion of IAM ‘standards’ is often a starting point for companies considering cloud identity. But standards alone should not drive architecture – projects are much better driven by use cases and risk. Our goal is to define an overall architecture which fits your organization, and apply appropriate communication standards after that. To help disentangle design from implementation standards, we will introduce design patters to describe the architecture. A design pattern is a universal model that both abstracts and simplifies the structure from underlying environmental complexities. For each use case we will describe a design pattern that address the core challenges of propagating identity information across multiple services. Then we will discuss how IAM technology standards fit within those models.

As previously discussed, there are three core cloud IAM use cases: Single Sign-on (SSO), Provisioning, and Attribute Exchange. Delivering on these use cases requires a number of architectural decisions and workarounds for various issues.

SSO Architecture and Design: Learning from the Pin Factory

One man draws out the wire, another straights it, a third cuts it, a fourth points it, a fifth grinds it at the top for receiving the head: to make the head requires two or three distinct operations: to put it on is a particular business, to whiten the pins is another … and the important business of making a pin is, in this manner, divided into about eighteen distinct operations, which in some manufactories are all performed by distinct hands, though in others the same man will sometime perform two or three of them.”- Adam Smith, 1776

SSO is often implemented using a ‘federation’ model, under which each user’s identity and associated attributes are stored across multiple distinct identity management systems. Which identity management repository within the larger federated group determines whether to validate a user is determined dynamically at request time. Federated identity is tailor-made for the cloud because it cleanly separates responsibilities between the enterprise and the cloud provider. As in Adam Smith’s pin factory, each participant can specialize in the areas they are best able handle, and the identity protocol establishes the mode of exchange between participants.

SAML has been the dominant standard in this area, used by enterprises and cloud providers to coordinate SSO. SSO architectures implement one or more Identity Providers (IDPs) which act as authoritative sources for account information. The IDP is generally on the enterprise side, but may also be kept in a separate external IDP cloud. While SAML is the runtime identity protocol for SSO exchanges, the IDP is the linkage point between the service provider (the external application) and the provisioning services which manage the accounts (typically the HR database).

The Relying Party (RP) is generally implemented on the cloud provider side; its task is to consume and verify identity assertions and ensure proper access rights to the cloud application. The agreement point between the IDP and the RP defines the identity protocol, how it is initiated (from enterprise the and/or cloud provider side), the schema, which attributes are sent, and any additional details.

Federated Identity enables the enterprise, as the party with the freshest and most accurate user information, to control and manage accounts. The cloud provider controls the application side, and can consume and use assertions from the enterprise without the burden of user management.

Federation enables Single Sign On for an open, interactive application architecture. The technologies that deliver these services place a premium on uptime (measured in “multiple 9s”) and robust performance because of the importance of timely and accurate information from trusted identity source. Given the heavily reliance of cloud services on high-bandwidth low-latency network access, integration with browsers and clients is necessary. Any standard used for federation must be resilient in the face of privacy and integrity attacks, at both browser and protocol layers.

Provisioning Architecture and Design: Process Automation

Provisioning systems are architected very differently than the SSO/federated systems discussed above. Provisioning is less about architecture and more about process, with a focus on how and when systems communicate. Provisioning systems don’t need real-time synchronization – they often run in batch mode, perhaps hourly or even daily. Provisioning systems are used as back-office support applications, so design requirements center around integration – largely having to do with the byzantine protocols necessary to communicate with directories and vendor packages. The good news in terms of security is that these services are less exposed than other systems, requiring neither browser integration nor direct exposure to users.

Provisioning processes such as ‘onboarding’ new users, updating accounts, and managing users, are highly automated. The back-end processes to update and synchronize data are critical in traditional on-premise IAM systems, to ensure users don’t unwarranted access to data, and that former employees do not retain system access rights. Extending these functions beyond the corporate IT perimeter is inherently difficult. Like football referees, these systems are only visible to users when they fail.

The unique aspect of provisioning cloud applications is its focus on process automation across a least two companies – the enterprise and the cloud provider. We don’t hear many success stories of process automation across multiple companies. Fortunately the handoff of accounts to the cloud provider is relatively simple.

There are tree key architecture decisions for provisioning systems, but in the end they all come down to the same thing: location, location, location.

• Where will the authoritative source reside? In the cloud or on the enterprise side?
• Where will the target (IDP) reside?
• Who manages the provisioning system and related policies? What interfaces are used?

Historically, provisioning has not been an area of focus for standards. While SAML is a well-used standard, SPML (Service Provisioning Markup Language) did not achieve broad adoption, nor does it ever appear likely to. SCIM (System for Cross-domain Identity Management) has largely filled this gap, and appears well positioned to provide a standard that satisfies cloud requirements.

SCIM was designed to be used across domains, making it ideal for cloud services. Schemas include users and groups, so authentication and authorization information can be updated. Basic operations are available through a simple REST API – including creation, reading, replacement, deletion, updating, searching, and bulk updates of users and groups. That helps map existing processes into these operations and extend them to cloud applications.

Attribute Exchange Architecture and Design: … and Everything Else …

Of course identity is not just about SSO and provisioning. Attribute exchanges are used to provide information about users and applications, and to make attribute-based access control decisions. For example an attribute might be a unique user identifier, a sign of group membership, or an indication of policies which apply to the user session.

This is where our three use cases combine to deliver value. Provisioning systems provide fresh and accurate information from the authoritative source (directory services). Identity protocols such as SAML move it around within the system, ferrying data to the cloud applications. But this is all for naught unless and until those attributes are used to enforce access control decisions. User identity and authorization maps must actually do something, and attribute exchanges is how we set these policies. We don’t want attributes hard-coded into applications – especially because SaaS providers serve many different customers. Instead it should be quick and easy to change policies without recoding applications or services.

The beginning of this journey is in the Policy Enforcement Point (PEP) that gathers attributes, and the Policy Decisions Point (PDP) that maps target rules to provide a yes/no access answer. These two building blocks form the simple producer/consumer design pattern for central policy creation and management with distributed enforcement.

XACML (eXtensible Access Control Markup Language – recently standardized to v3.0) provides an end-to-end standard for authoring authorization rules and policies. Chief among its advantages is that authorization logic is removed from code. This makes it easier to change and audit, and more dynamic so authorization can be data-driven rather than hard-coded.

Unlike the SSO and provisioning architectures, the majority of the access control runtime is likely to reside at the cloud provider. The enterprise can serve as policy author and expose a policy information point (attributes used for access control decisions) but for performance and integration reasons it almost always makes the most sense to have the policy decisions and enforcement on the cloud provider side.

Where does this leave the enterprise? The XACML standard alone cannot provide everything they need. To take advantage enterprises must be able to write and update policies to drive authorization on the cloud provider side. This can be managed at a several different levels of granularity, from coarse-grained Roles (RBAC) to fine-grained dynamic Attribute Based Access Control. The common thread across all these approaches is a defined entry point which exchanges attributes to drive the access control workflow.

The point of standards is not compliance for its own sake, but a standard to enable the use case to work. The function of identity standards is to establish proven and reviewed protocols that vendor lock-in to either the cloud or identity vendor, at low cost. We bring up this distinction because we often hear companies say “standard XYZ is our identity architecture.” But this misses the point: the use case drives the architecture; the standard plays a supporting role. This is the approach to take when considering cloud IAM solutions.

Our next post will tackle the most difficult challenge: an implementation roadmap for cloud IAM projects. There are a couple places where many projects stall or fail outright; so we will offer guidance on setting goals, which pieces you should tackle first, and setting expectations with management and teammates.