Just-In-Time Versus Asynchronous Provisioning

There are multiple options for getting identities into and out of external service providers (SP).  This is often dependent on what the SP supports.  Some SPs support Just-in-Time (JIT) Provisioning, which means that the service provider will consume SAML attributes upon login and either create the user if he/she doesn't already exist in the SP's user store, or update the local account if any of the attributes differ from what is sent in the assertion.  This is secured by the inherent trust of the SAML authentication.  The downsides of JIT provisioning are that you typically cannot de-provision a user.

Asynchronous provisioning utilizes some kind of scheduled job or user interactive method of synchronizing identities from one or more sources to the service provider.  This typically involves a polling of the authoritative user store and pushing any adds, deletes, inactivates, changes, etc. into the target.  The target service provider must provide some kind of provisioning service in order for this to work.   Many of the provisioning vendors have implemented connectors/adapters for SPs like Google, WebEx and SalesForce using their respective APIs.  Each of these are one-off implementations and most SPs don't provide any kind of public provisioning hooks today.

An Oasis standard called SPML for provisioning was created over 10 years ago, but has lacked in adaption (so much so that I won't bother to even spell out the acronym).  Its failure was likely in its lack of granularity for updating profiles and the general complexity of implementing a SOAP-based service.  Simple Cloud Identity Management (SCIM) is a likely successor for SPML.  Plenty of information on SCIM at http://www.simplecloud.info, but SCIM's use of REST and the timely need for it with the proliferation of cloud service providers will drive higher adaption.

This matters because the natural progression of these cloud providers will be the aggregation of these services into packaged offerings.  Identity propagation will be key to enabling these aggregations and you can't propagate identity easily without having an account at the SP.  Thus, end-to-end user lifecycle will require that accounts are provisioned and de-provisioned from the SPs from that 3rd party aggregator.   SCIM enablement will be a big land grab for provisioning vendors going forward.