This post delves into why companies are looking at new Identity and Access Management technologies for cloud deployments. Cloud computing poses (sometimes subtly) different challenges and requires rethinking IAM deployments. The following use cases are the principal motivators listed by organizations moving existing applications to the cloud – both internal or external deployments – along with how they integrate with third party cloud services.

IAM architecture often feels pretty abstract; describing traits is a bit like postulating how many angels can dance on the head of a pin or whether light behaves more like a particle or a wave. And then there are standards – lots and lots of standards. But use cases are concrete – they show the catalyst, the activity, and the value to the enterprise and the user. Instead companies should start their decision process with use cases and then look for identity technologies and standards, rather than the other way around.

To help understand why cloud computing requires companies to re-think their Identity and Access Management strategies, we will provide a handful of cases that illustrate common problems. The following cases embody the catalysts for altering IAM deployment structure, and embody the need for new protocols to propagate user privileges and establish identity in distributed environments.

Before we get to the use cases themselves let’s look at the types of actors IAM introduces. There can be numerous different roles in a cloud IAM system, but the following are part of most deployments:

• Identity Provider: Consulted at runtime, the IdP is an authoritative source of information about users. This is often Active Directory or an LDAP server – which in turn provides token to represent the user identities. Cloud computing architectures often include more than one IdP.
• Relying Party: An RP is an application that relies upon an Identity Provider to establish identity. The relying party validates the provided token as genuine, and from the identity provider, and then uses it to assert the user’s identity.
• Attribute Provider: An AP either has access to or directly stores the fine-grained attributes that define user capabilities. Permissions may be role-based, attribute-based, or both. The value proposition is that attribute provider enable dynamic, data driven access control. This information is critical – it defines application behavior and gates user access to functions and data. How it provides attribute information, and how it integrates with the application, varies greatly.
• Authoritative Source: This is the authority on identity and provisioning settings. The AP is typically the HR system that stores master identity records, used as the source of truth for account status. This system has rights to add, edit, and disable accounts from other systems – typically via a provisioning system. For legal and compliance requirements, these systems keep detailed transaction logs.
• Policy Decision Point: The PDP handles authorization decisions by mapping each access request to a policy. This may be performed in application code or as a separately configured policy.

There may be other IAM system roles in your deployment, but the above is the core set for cloud IAM. The location of each of these services varies, along with whether each role is supplied by the cloud provider and/or the enterprise, but these roles factor into every cloud deployment.

Most cloud deployments address some combination of these three IAM Use cases:

Use Cases

Single Sign On

Single sign on is the single greatest motivation for companies to look at new IAM technologies to support cloud computing. And for good reason – during our careers in security we have experienced few occasions when people have been glad to see security features introduced. Single Sign On (SSO) is one happy exception to this rule, because it makes every user’s life easier. Supply your password once, and you automagically get access to every site you use during the course of the day. Adding many new cloud applications (Salesforce, Amazon AWS, and Dropbox, to name a few) only makes SSO more desirable. Most security does not scale well, but SSO was built to scale.

Behind the scenes SSO offers other more subtle advantages for security and operations. SSO, through management of user identity (Identity Provider), provides a central location for policies and control. The user store behaves as the authoritative source for identity information, and by extending this capability to the cloud – through APIs, tokens and third party services – the security team need not worry about discrepancies between internal and cloud accounts. The Identity Provider effectively acts as the source of truth for cloud apps.

But while we have mastered this capability with traditional in-house IT services, extending SSO to the cloud presents new challenges. There are many flavors to SSO for the cloud, some based on immature and evolving standards, while other popular interfaces are proprietary and vendor-specific. Worse, the means by which identity is ‘consumed’ vary, with some services ‘pulling’ identity directly from other IT systems, while others requiring you ‘push’ information to them. FInally, the protocols used to accomplish these tasks vary as well: SAML, OAuth, OAuth II, vendor APIs, and so on. Fortunately SAML is the agreed-upon standard, used in most cases, but it is a complex protocol with many different options and deployment variations.

Another challenge to cloud SSO is the security of the identity tokens themselves. As tokens become more than just simple session cookies for web apps, and embody user capabilities for potentially dozens of applications, they become more attractive as targets. An attacker with an SSO gains all the user rights conveyed by the token – which might provide access to dozens of cloud applications. This would be less of an issue if all the aforementioned protocols adequately protected tokens communicated across the Internet, but some do not. So SSO tokens should always be protected by TLS/SSL on the wire, and thought should be given to a protection regime for token access and storage from applications.

SSO makes life easier for users and administrators, but for developers is only a partial solution. The sign-on process is simplified, but the granularity of attributes and hooks into the Relying Party authorization code still require careful design and development.

Finally, we have a problem with the inverse of SSO: SLO (Single Logout). “What do we do when a user logs out?” If the user is logged into many applications, do we terminate just one session or all of them? Even if you have want all sessions to close, most SSO systems are unable to clean up running sessions for you. You will need to review session management and activity timeouts in conjunction with SSO system capabilities. These should be tested to ensure the application itself is not keeping sessions open and ignoring established policies. SLO is almost universally mentioned in company RFIs and RFPs, but in practice is rarely implemented. Instead companies rely on automatic session timeouts and other techniques for cleaning up SSO sessions.

Provisioning

As we add new cloud applications and services, how do we enable, or add, our users to those services? This is called provisioning, and is how we provide user account information to cloud applications. There are several possibilities, and customers may employ one of more of the following steps, typically combined into a provisioning process:

1. Account registration: Create a new account in the cloud service, seeding information from an authoritative source such as the HR System.
2. Account propagation: Synchronize or replicate accounts to the cloud provider, usually from directory services.
3. Account management: Update account status, attributes, groups, roles, and other account information.
4. Account disable: Disable access to functions or applications.
5. Audit: Track the end-to-end activities of users and use of access rights management. This includes both ongoing activity monitoring and periodic policy review, for concerns such as separation of duties.

This lifecycle can be managed in-house within the company, and then synchronized to the cloud provider. Or it can be done wholly at the cloud provider, but this increases risk because the cloud provider needs the complete set of user credentials, perhaps in a multi-tenant cloud environments, and generally requires greater effort as well. The third option is outsourced Identity Management as a Service providers – actual IAM cloud services. A handful of vendors can bridge your internal systems with external cloud providers, taking care of the synchronization and integration of cloud services. Many vendors offer the IDM lifecycle via a separate IDM cloud and associated management UI.

Attribute Exchange

Traditional enterprise IT and cloud provider systems need coordinated data management. Information may be held by one or both parties so synchronization is key. Data exchange occurs through gateways, web services portals, Enterprise Service Buses (ESBs), or application identity – systems that make decisions based on an application identity rather than user identity.

Application identity is one area where cloud providers are often ahead of standard practice in IT, because each host is typically assigned its own account, rather than being managed as an ad hoc process. These identities – whether ESB, gateway, application server, or other, tend to be longer-lived; so different protocols may be in play. Application identity may be managed with “old school” x.509 certificates – as with Amazon AWS – but these attribute exchanges lend themselves to protocols designed to handle such issues, such as SCIM for provisioning and SAML for SSO. For finer-grained operations or ‘fresher’ data, x.509 is often not good enough. Security Token Service (STS) may be used to broker identity interactions. One factor to condider in this use case is the role of the client. In some operations such as API security, WS-Trust, and OAuth, the client is responsible for performing the legwork of setting cookies and session data, and navigating the protocol dance between client and server. In other settings such as SAML and browser-based security, the client may be passive, with the server initiating operations and the client to receiving and responding to messages.

Whether old school or new school, Attribute Exchange use cases are the duct tape of identity; they cover a wide variety of integration scenarios, from sharing identity on the latest smartphones to backend legacy messaging systems. Identity is the management of sharing, and attribute exchange helps to scope these interactions. No single product or protocol can achieve full end-to-end coverage, but it is essential for the architect to factor in the full chain of responsibilities to maintain high quality and integrity for identity data.