“The Cloud” is a term so overused and often misapplied that it has become meaningless without context. This series will discuss identity and access management as it pertains to the three major cloud service models (Infrastructure, Platform, and Software). Each of these models (SaaS, PaaS, and IaaS) presents its own unique challenge for IAM, because each model promotes different approaches and each vendor offers their own unique flavor. The cloud service model effectively acts as a set of constraints which the IAM architect must factor into their architecture.

With the SaaS model most enterprises look to federated identity, meaning the enterprise uses federation capabilities to gate access to cloud applications, keeping control over provisioning accounts internal. This approach is both simpler and offers better security policy control than the primary alternative, of replicating accounts into the SaaS provider – copying big chunks of user directories into the cloud. A middle road has emerged where account management is available via a Identity as a Service cloud provider; we will discuss this later in this series.

For IaaS, Identity Federation is an option as well, but the need is not as great because you manage everything above the Infrastructure level. Infrastructure providers have some built in capabilities for identity management, but since you control most of the infrastructure, extending your current capabilities into the cloud is a more natural progression. IaaS vendors like Amazon’s AWS have offered limited support for federation over the years, but the quality and depth of their functionality demonstrates that the service providers largely expect customers to handle this. PaaS, as usual, is somewhere in between. Most PaaS service providers offer more robust capabilities, so federation is a first-class choice in most major platforms today.

Cloud Identity Deployment Models

IAM deployments for the cloud generally use some combination of the following approaches: * Store Accounts in the Cloud: This is exactly what it sounds like: copy your existing accounts into the cloud environment. You effectively replicate or synchronize enterprise user accounts into the cloud provider’s environment. It is conceptually very simple, and as most IT departments are already familiar with directory services, it’s the easiest way to get started in the cloud. It is also a model that creates security problems when you replicate – and potentially expose – sensitive information including keys, passwords, and other access control data. Remember, “The Cloud” is naturally a multi-tenant environment, shared by other customers and administrators not on your staff. Role changes, as well as account removal or disabling, can lag unacceptably before the internal change is effective at the cloud provider. * Federation: The next option is federation, where user identities are managed locally but identity assertions can be validated through tokens presented to the cloud service interface. The enterprise retains local control and management, typically via Active Directory. This removes the issue of secret data (such as passwords) being stored in the cloud. Federation lets the enterprise leverage existing IDM processes, possibly across multiple systems, which simplifies management and provisioning. * IDMaaS: Identity Management as a Service is an emerging architecture to watch. This is effectively a hybrid of the first two approaches. A separate cloud is run for identity management, usually managed by a different cloud service provider, who links directly to internal on-premise systems for policy decision support. One of the major advantages of this approach is that the IDMaaS provider then links you to various cloud services, handling all their technical idiosyncrasies behind the scenes. The IDMaaS provider effectively glues everything together, providing identity federation and authorization support.

IAM Service Delivery

Most cloud deployments today mainly work toward leveraging federated identity, but this is where the commonality stops. The way identity is used, and the types of IAM services available, cover a wide range of possibilities.

• Authentication: A deceptively simple concept, which is devilishly hard in practice. As IT managers and programmers we understand in-house authentication – but what about cloud apps, middleware, and proxies? What about privileged users? Where and how is the session controlled? And how are authentication events audited? Authentication is one area most enterprises think they have nailed, but the edges and external interfaces add complexity and raise questions, which are not yet fully addressed.
• SSO: Single sign-on is table stakes for any cloud provider, but the way it is delivered varies between providers and service models. SSO is a subset of federated identity, and provides the seamless integration users demand. Enterprises should seek cloud providers with open standards based SSO to reduce complex and costly integration work.
• Standards: First, the good news: there are many identity standards to choose from, and each excels at one aspect of identity propagation. The bad news is there are many identity standards to choose among. Choose wisely – cloud IAM architecture should be standards-based, but the standards should not drive the cloud IAM architecture.
• Federation: Federation of identity is another sina qua non for SaaS, and a basic capability of most cloud service providers. Key success factors include integration for the federation servers to cloud consumer and cloud provider.
• Authorization: Identity defines “who is who”, and authorization then defines what those users can do. Traditionally users are assigned roles which define what they can do and access. This makes administration easy, as a single change can update many users with the same role. But roles are not good enough any more; apps need attributes – granular characteristics – provided by an authoritative source. The question is: where are they? Cloud side, enterprise side, or both? Policy-based authorization via XACML is steadily growing trend. Today XACML is more likely to factor into PaaS and IaaS deployments, but it is likely to be the de facto authorization standard in the future.
• Provisioning: Account and policy lifecycle management – including user account creation, propagation, and maintenance – is primarily an enterprise function. Cloud apps are just another endpoint for the provisioning system to speak to. SCIM is a proposed standard for provisioning, but some people use SAML beyond its intended scope to effectively replicate SCIM’s provisioning functions.
• Audit: An issue in all cloud deployments, authentication and authorization services need a way to publish events to an audit repository, which is generally kept on the enterprise side. This is another “must have” for cloud services and data which fall under corporate governance – but auditing capabilities are currently neither ubiquitous nor complete. SPML is a proposed standard for auditing cloud IAM, but has had limited traction to date.

Integration

Unlike most IT functions as it relates to identity, the enterprise is still responsible for quite a lot.

• Process Integration: Provisioning and policy management systems are not technology-centric so much as business-process-centric. Making sure these are cloud-ready means updating processes to account for cloud providers’ roles, responsibilities, and limitations.
• First Mile Integration: To establish federation, the enterprise identity provider must be integrated with an authentication and/or attribute source. For IDMaaS this is usually an on-premise appliance or piece of software that provides a communication tunnel to the service provider. Most often this is custom code or federation extensions atop existing directory services.
• Last Mile Integration: The cloud provider’s systems must be able to consume the identity and bootstrap the user into the cloud app, and the identity’s relying party must have adapters to integrate to the cloud provider. The communication protocols may be industry standards such as SAML or vendor-specific APIs.

We have covered a lot of material here, so we encourage comments and questions.