SCIM Simplifies Cloud Service Identity Provisioning

Update: My RunAs Radio interview about SCIM is now available.

****

This month, I thought I’d update you about some important work that’s going on in the arena of cloud identity standards. You’ve probably never heard of the Simple Cloud Identity Management (SCIM) specification, but within a year it will affect some of the key areas you work on as an identity professional.

A Foray into IAM

Before I get into the problem that SCIM is being designed to solve, I think a little background would be helpful. You can broadly carve up identity and access management (IAM)—whether it’s on premises or in the cloud—into four categories sometimes called “the four A’s.”

Authentication. The first and most obvious category is authentication (often abbreviated AuthN), which is the verification of an identity assertion (e.g., “I am Sean Deuby”) by a trusted authority (Penton Media’s Active Directory—AD). Authentication is by far the most mature of these four cloud identity areas, with a variety of available standards and technologies, though its cloud version is still far from overall maturity.

Authorization. The second cloud identity category is authorization (AuthZ, also referred to as access management), which is the process of granting access to an identity by a trusted authority to specific resources. For example, I’ve been granted access to certain network shares on a Fort Collins file server by Penton’s AD administrators. In the cloud identity world, authorization is still immature, and implementations vary from one cloud service provider to another, though standards such as eXtensible Access Control Markup Language (XACML) are growing in acceptance.

Audit. The third category is audit, which for the purposes of this article I’ll define as the recording and verification of IAM-related activities. Auditing, at least as far as cloud services go, is also a relatively immature area. The Cloud Security Alliance (cloudsecurityalliance.org) has assumed ownership of the CloudAudit project “to provide a common interface and namespace that allows cloud computing providers to automate the Audit, Assertion, Assessment, and Assurance (A6) of their infrastructure (IaaS), platform (PaaS), and application (SaaS) environments and allow authorized consumers of their services to do likewise via an open, extensible and secure interface and methodology.”

Accounts. The last of the four cloud identity categories is accounts. An integral task of any IAM system is dealing with user accounts and user groups. The lifecycle of working with these groups is often abbreviated as CRUD: Create (aka provisioning), read, update, and delete (aka de-provisioning). This identity area is more mature than audit or authorization, but it’s had its share of growing pains.

How do you go about provisioning accounts in the cloud? This can currently be handled in a number of different ways. First, you can simply bulk load accounts into the service provider with a .csv file, or otherwise manually provision them. Obviously, this is a function where automation is extremely important; not only is manual account provisioning not scalable, it’s insecure. Unfortunately, this is the only method most service providers give their customers.

A much smaller subset of service providers has moved beyond these simple methods and provides proprietary APIs or dedicated connectors for provisioning (which therefore can’t be re-used for the next service provider), or they support directory synchronization (where the contents of an AD container such as an organizational unit—OU—are duplicated and kept in sync at the service provider). A very few support IAM standards such as Security Assertion Markup Language (SAML) for just-in-time provisioning. There is a standard specifically for provisioning called Service Provisioning Markup Language (SPML), but the industry hasn’t adopted it.

Why Didn’t SPML Work?

It seems that one of the things that sunk SPML is that it was designed to be a complete solution to fit all situations, and therefore too ponderous to easily implement for most service providers. As Patrick Harding of Ping Identity also mentions in his post about SCIM, this reminds me of why we’re using Lightweight Directory Access Protocol (LDAP) instead of DAP for directory access. Have you ever heard of DAP? Have you ever wondered why a directory access protocol had to be named “lightweight” if there wasn’t something heavyweight in its past?

Why is all this talk about provisioning methods important? Because as you begin to use cloud service providers, you need to provision, manage, and de-provision accounts on the service provider. Thus, you should know what different methods are available and which are superior. Once you understand them, you can make the provisioning methods that a potential cloud service provider supports a criterion to use when you’re evaluating them.

What the cloud computing world needs is a standard for user provisioning that everyone can use so that they can get on with their main business of providing and using services. It’s always good for us identity types to be reminded that identity management isn’t the end goal; it’s only a means to an end. And it should be as simple, transparent to implement, and secure as possible. This is what SCIM is designed to help with.

The best summary of SCIM comes from its simplecloud.info home page: “The [SCIM] specification is designed to make managing user identity in cloud-based applications and services easier. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models.”

(Before I describe SCIM in a little more detail, let’s get the inevitable SCIM jokes out of the way. First joke: Since it’s about provisioning, SCIM is more accurately described as user management than identity management—but then it would be SCUM. Second joke: If you used “access management” or “attribute management,” then you’d have SCAM. So, its creators have settled for the slightly less accurate, but far more palatable nomenclature of identity management.)

Coming from the lessons of SPML, the first S of SCIM is important: It’s designed to be simple. SCIM doesn’t try to cover every provisioning situation; rather, it just covers the most common use cases and as a result is much simpler than SPML. It can handle creation, update, and deletion of users and groups; search; XML and JSON representations; and SAML binding for just-in-time provisioning.

SCIM has a common user schema, so name-value pairs (e.g., first name, last name, email address) mean the same thing regardless of which SaaS vendor you’re provisioning to, and this schema can be extended if necessary to handle specific identity or service-provider requirements. It uses a RESTful API, which makes it easier to integrate into existing cloud services. And SCIM has been designed to be fast for the service provider to implement. At the last Internet Identity Workshop (IIW) in October, developers for service providers were implementing SCIM-compliant connectors with a single day’s work.

Unlike with SPML, the industry itself has been developing this specification based on practical experience. Salesforce.com, Cisco, Google, Ping Identity, Technology Nexus, and UnboundID, among others, are committed to its success and are actively putting the polishing touches on a 1.0 version of this specification.

It seems to me that SCIM and SPML represent yet another example of the 80/20 rule: Support 80 percent of the provisioning use cases out there, and the spec will be simpler because it’s the remaining 20 percent that requires all the extra complexity. If you really need that 20 percent capability, and you can’t get it done with a SCIM schema extension, it’s probably OK that it needs a proprietary solution.

Another driving force behind SCIM is the need for speed. As we all know, the use of cloud services—especially SaaS applications—is exploding. Every day that we move forward without a provisioning standard, more cloud service providers are forced to come up with their own proprietary ways of giving identity providers access to their services and will have to retrofit a standard into their service.

SCIM’s Status

But SCIM is moving forward quickly. At the IIW in October, there were numerous vendors doing interoperability testing of SCIM with their services, including Salesforce.com, which developed a functional SCIM endpoint from scratch while at the workshop. As of December, the SCIM working group is expected to declare a version 1.0, and Harding (one of SCIM’s key initiators) believes that Google Apps, Cisco Webex, and Salesforce.com will all have working SCIM endpoints in production at some point in 2012.

Is there anything you should do? You need to demand that your cloud service providers support the emerging SCIM specification for provisioning. It will be easier and cheaper for you because you won’t need a specialized connector, and it will be better for the service provider because it can provide a standard provisioning interface to its customers.

For more information, see SCIM’s home page. Ping Identity has a short SCIM tutorial, Trey Drake of UnboundID has a Mythbusters-like SCIM FAQ, and Chris Phillips of CANARIE has a nice PowerPoint overview of SCIM.

FSean writes about cloud identity, Microsoft hybrid identity, and whatever else he finds interesting at his blog on Enterprise Identity and on Twitter at @shorinsean.