Provisioning Standards

Last modified 22 Apr 2021 17:31 +02:00

Generally we try to avoid reinventing the wheel if possible. Therefore we see industry standards as a good thing as longs as long as they are practical. Therefore are more than happy adopting established standards that work acceptably well, such as SQL and LDAP. But we are quite vary about newer standards and specifications that were not proven yet. Too many of these suffer from premature standardization problem. We are pragmatic. We make use of technologies that what works well and we avoid those that do not. Our goal is a working software not a pile of papers stating compliance with standards.


SCIM is an IETF effort to establish a standard for universal identity provisioning interface. Unfortunately SCIM is repeating almost all the mistakes of its predecessors. SCIM has many problems that are described in SCIM Troubles page.

SCIM in midPoint

We see SCIM effort as typical example of premature standardization. SCIM team tries to standardize a solution to a problem that is not yet well understood. It is more than likely that such a solution will be unsatisfactory. How can anyone design a solution to a poorly understood problem without experimentation? Without feedback from real implementation?

Our approach to standardization is actually quite the opposite to that of SCIM: we want working solution first, use it to experiment and understand the problem, design an improved solution, prove it using a working software, repeat these steps many times until a good and generic solution is developed. And only then force the others to use the solution (a.k.a. "standardize"). This is iterative and incremental development model that works well for complex and poorly understood problems. And the entire identity management field is full of very complex and quite poorly understood problems. Therefore MidPoint follows this incremental and iterative path to development of provisioning interfaces.

Overall we consider SCIM not to be a very practical solution. MidPoint tries to be a practical system therefore it is natural that support for SCIM is limited:

  • MidPoint has currently partial outbound support for SCIM. There are several SCIM-based connectors for a specific systems. There is no universal SCIM connector as SCIM does not guarantee interoperability. And unless SCIM specification are significantly improved, there may never be one.

  • MidPoint does not provide SCIM service. However, there are some information suggesting that such a service may be provided as a contribution to midPoint project.

We rather recommend an alternative approach to SCIM when dealing with target systems: connectors. MidPoint is build for integration. Therefore there is no need to make a (potentially costly) changes to your target application to support SCIM and then also do the integration work on midPoint side to configure and profile SCIM dialect for that particular application. It is much easier and usually also less expensive to create ConnId connector for such application and use native API of such application for communication. The integration work on midPoint side still needs to be done but that’s what midPoint was built for. That’s probably the most efficient, reliable and maintainable approach. At least until SCIM (or any of its successors) matures.