Provisioning Standards
Identity provisioning is a subfield of identity governance and administration (IGA), concerned with technical aspects of creating user accounts, groups and other objects in target systems. It is a technology thanks to which many identity stores are synchronized, merged and maintained. Identity provisioning takes care of technical tasks during the whole user lifecycle - when new employee is hired, when their responsibilities change, or when they leave the company (deprovisioning).
Almost all applications and systems expose interfaces (APIs) for the purposes of user, entitlement and access management. Traditionally, such provisioning interfaces were very heterogeneous. Each application implemented its own flavor of the interface, supported by its own data model, operations and specific details. Of course, heterogeneous interfaces make integration very difficult.
Standardization History
Heterogeneity of identity provisioning interfaces is quite undesirable. Quite naturally, there were attempts to align the interfaces and introduce provisioning standards. First attempts date back to the late 1990s and the early 2000s, however these have caught almost no attention, and they are generally lost to history. Perhaps the only legacy from these times are attempts to use LDAP and its XML-based variant DSML as a form of provisioning interface. Even though identity field has a long tradition to abuse LDAP for functionality that it was never supposed to provide, this approach has failed this time. LDAP cannot be really hammered into a provisioning interface.
Then the 2000s brought a quick succession of two Service Provisioning Markup Language (SPML) versions. The two SPML versions were very different, trying two different approaches to standardized identity provisioning. However, both versions had one thing in common: They both have failed spectacularly, not bringing any real value.
Then the 2010s brought its own take on standardized provisioning interface, in a form of Simple Cloud Identity Management (SCIM). As the initial release of SCIM followed in SPML footsteps, it is perhaps not surprising that SCIM 1.0 was not very successful. Fortunately, SCIM 1.0 was quickly replaced by SCIM 2.0, which finally gained some traction. The SCIM was eventually renamed to System for Cross-domain Identity Management, although the original name was much more fitting.
SCIM 2.0
System for Cross-domain Identity Management (SCIM) is an IETF specification (RFC7642) of a RESTful service for identity provisioning. SCIM specification describes services to create, read, update and delete (a.k.a. "CRUD") data about users and groups. SCIM services are provided by systems that store identity data, such as applications with their own database, cloud service providers and so on. SCIM services are invoked by software systems that need to manage the identities, such as IGA platforms.
Overall, SCIM 2.0 specification is quite vague. It provides a rough framework, rather than a strict specification of an interface. There are many problematic parts, efficiently ruining any kind of out-of-box interoperability.
Even though SCIM 2.0 is not a specification that can guarantee interoperability, it has some value. SCIM 2.0 does make integration of provisioning interfaces somehow easier. Even thought SCIM clients need to be customized for each and every SCIM service, such customization is easier than implementing a client for a completely custom interface.
SCIM 2.0 implementation are very unlikely to interoperate out-of-the-box. However, the effort needed to make them interoperate is somehow reduced as all the implementation are inspired by common SCIM specification. This is the real value of SCIM 2.0. It is not much, but it is still better than nothing.
Connectors
There is no interoperable identity provisioning interface yet. Despite that, identity provisioning mechanisms of IGA platforms needs to work. In fact, it is working relatively well since the early 2000s.
Every comprehensive IGA platform has a common provisioning interface inside. The interface is used to support connectors, adapters, integrations or whatever are they called in each specific platform. These interfaces work quite well. However, there are downsides.
Firstly, the interfaces are platform-specific. All the connector interfaces are bound to a specific IGA platform and connectors are not reusable. There is just one exception: ConnId connector framework. ConnId is an open source identity connector framework used by a couple of IGA platforms. However, even that does not make it a "standard".
Secondly, the connector interfaces are much more flexible and dynamic than is common for mere specifications. However, that also makes them complex. There is a lot of code supporting the flexibility, which make the complexity manageable. Creation and maintenance of connectors is still not entirely easy. Yet, it is feasible, and it provides (almost) out-of-the-box interoperability.
Conclusion
Identity provisioning standards are much harder than it may seem. Despite numerous attempts, we have not got to the "standard" thing so far. After (at least) three failures, SCIM 2.0 is the first attempt that have not failed immediately. However, SCIM 2.0 is not very successful at providing interoperability either.
So far, comprehensive IGA platform is still needed for any kind of identity provisioning interoperability. Connector framework that the IGA platforms provide, together with powerful data mapping capabilities are necessary to provide interoperability and enable automation. It is very difficult to predict whether this is about to change in any foreseeable future. However, the past record of provisioning standards as well as its latest iteration does not provide much hope.
For the time being, IGA platforms are the best options. They provide much more than just identity provisioning integration. There are policies, automation, access control models, compliance management and much more. IGA platforms are necessary, regardless of the future of any provisioning standard.