When we talk about provisioning cloud services, there is Just In Time (JIT) provisioning and bulk provisioning. JIT provisioning is where accounts are created as a side effect from federation. In other words, the first time a user federates to a service, his account is created using the federation token and information queried from the user. Bulk provisioning is where the accounts are created in bulk ahead of time and actively maintained independently from federation. The main problems with JIT provisioning are

  • A user is not visible in a service until he federates to that service, and;
  • There is no way to deprovision users without bulk provisioning. Because of this, most services offer bulk provisioning even if they offer JIT provisioning.

Now let’s talk about the good, bad, and the ugly of bulk provisioning.

First there is good bulk provisioning, using standard protocols. The most popular standard provisioning protocol today is SCIM 2.0 (https://tools.ietf.org/html/rfc7644). Optimal IdM is very much a believer in standard protocols, so of course the OptimalCloud supports SCIM 2.0, both for provisioning accounts to the OptimalCloud and the OptimalCloud provisioning accounts to other services.

Then there is the ugly bulk provisioning, file upload via SFTP, usually CSV files. While this approach is ugly and mired in last century technology, it actually works pretty well. Which is why this is by far the most common method used today. You would be surprised how many best of breed service providers out there still only support file upload provisioning. We are talking about services you are probably using today, but we are not going to name names.

Finally, there is the bad bulk provisioning, proprietary APIs, sync clients, and provisioning agents. Provisioning agents are software modules that must be installed on a provisioning target. Obviously, this is a non-starter for a cloud service. Sync clients are software modules that must be installed on a server where it can access the source of the provisioning data (typically AD). Sync clients are typically easy to install and configure, but limit the functionality and are hard to diagnose when something doesn’t work right. Proprietary APIs are APIs that are exposed to the client, but are non-standard and require significant coding efforts to integrate.

So, your assignment now is to start asking your service providers when they are going to support SCIM 2.0!