SPML and its limitations
The granddaddy of provisioning standards is certainly SPML. Originally published in 2003, SPML is a product of the OASIS Provisioning Services Technical Committee. OASIS defines provisioning as "the automation of all the steps required to manage (setup, amend and revoke) user or system access entitlements or data relative to electronically published services."
The Statement of Purpose for the Provisioning Services TC explains the need for interoperable provisioning services for both intra-enterprise and inter-enterprise use, and which can transcend the boundaries of a single security domain in order to manage identities across domains. To that end, SPML is "a standard, XML-based framework for creating and managing information that represents user identities and related entities."
SPML supports operations for listing "target" objects that receive provisioning requests, adding objects (access and entitlements) to those targets, modifying objects, and deleting objects. Support is also provided for setting, expiring, resetting, and validating passwords, as well as for temporarily suspending (and later reactivating) user accounts. The standard provides support for asynchronous mode and for bulk operations too.
Using SPML, it becomes possible to programmatically automate the provisioning of user access and entitlement rights, across a wide range of services. Of course, for this to be possible, the target services must provide SPML -- and there's the rub. While this specification has been around for years, enjoys multiple solid implementations (including open source implementations), and has historical roots in the world of the wildly successful LDAP, it simply has not been widely adopted. This is even truer in terms of SaaS and cloud provisioning. You may find individual enterprises that use SPML for automatic provisioning behind the firewall, but not many SaaS providers support SPML -- yet.
Why has the SaaS world been so slow to adopt SPML? One reason is that we are only now reaching the tipping point where any one organization uses enough different SaaS applications from a variety of vendors that provisioning overhead has become a significant problem. Up until now, there was little reason for the provider of a SaaS app to worry about supporting programmatic provisioning, since no one was asking for it. The second reason, vis-a-vis SPML in particular: SPML is complicated. It works -- and works well -- for its intended purposes, but it is not a simple protocol, and integrations using SPML can be somewhat complex. This friction has served to slow down its adoption in the SaaS world.
Searching for standards
If not SPML, then what mechanism will simplify cloud provisioning? The new kid on the block is a protocol known as SCIM (system for cross-domain identity management). Developed under the auspices of the IETF, SCIM is more specifically designed for managing user identities in cloud-based applications and services.
SCIM has a modern feel to it, because the specification defines both JSON and XML encodings, and the spec defines a RESTful interface for provisioning operations. SCIM also has the backing of two giants in the cloud world: Google and Salesforce. The SCIM protocol specification is in draft status at this time, but the core schema has been submitted as a Proposed Standard, and the IETF Working Group road map calls for completion in early 2014.
In addition to SPML and SCIM, a handful of other standards exist that address varying aspects of automated provisioning. XACML, another OASIS standard, focuses tightly on managing access control lists in a security environment using ABAC (attribute-based access control). RBAC can also be implemented using XACML by treating it as a specialization of ABAC.