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 ( 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!


  • The database in which all of your organization’s sensitive identity data is stored.
  • A digital ledger in which digital transactions are recorded chronologically and publicly.
  • Securely managing customer identity and profile data, and controlling customer access to applications and services.
  • The means of linking a person's electronic identity and attributes, stored across multiple distinct identity management systems.
  • A legal framework that sets guidelines for the collection and processing of personal information of individuals within the EU.
  • The policy-based centralized orchestration of user identity management and access control.
  • An authentication infrastructure that is built, hosted and managed by a third-party service provider.
  • A security system that requires more than one method of authentication from independent categories of credentials to verify the user's identity for a login or other transaction.
  • A global provider of innovative and affordable identity access management solutions. 
  • Managing and auditing account and data access by privileged users.
  • Tools and technologies for controlling user access to critical information within an organization.
  • An authentication process that allows a user to access multiple applications with one set of login credentials.

Pin It on Pinterest