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 and over-complicated standards and specifications such as the WS-* stack. We use the parts of such specification that work well but we have no ambition for full compliance. 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.
Service Provisioning Markup Language (SPML) was an effort of OASIS to standardize interaction in provisioning deployments. Although SPML partially works, it is now generally considered as obsolete. There are two versions of SPML specifications
- SPML version 1 is quite simplistic specification very similar to DSML, which is in turn mostly LDAP over XML. SPMLv1 is practical for some simple deployments but its capabilities are limited to the very basics.
- SPML version 2 is considerably complicated specification. It is designed to be very flexible but the flexibility is also its primary failure as a standard. SPMLv2 defines very little details to be used as a communication mechanism between out-of-the-box systems. E.g. SPMLv2 does not specify standard user schema. Due to SPMLv2 flexibility it is almost impossible to maintain interoperability of SPMLv2 implementations that go beyond the very basic scenarios. Practical usability of SPMLv2 is very limited.
SCIM is an IETF effort that targets almost the same problem as SPML. Unfortunately SCIM is repeating almost all the mistakes of SPML. Athough SCIM specifies a standardized user schema the definition is very vague. Two systems that both support SCIM might be able to communicate on a very basic level (create account, delete account). But SCIM needs to be heavily profiled for any kind of slightly complex provisioning interaction. E.g. SCIM includes very vague and slightly inconsistent definition of group/role membership, account activation (e.g. activation times) and other "advanced" features. However according to our experience such "advanced" features are critical for most IDM deployments. It is unlikely that SCIM could be used to connect two systems without a heavy customization and profiling on both sides of a communication channel - which somehow spoils the entire idea of provisioning standard.
We have tried to contribute some of our ideas to the SCIM standardization team quite early in the process. The ideas were not understood. Now we are closely watching SCIM effort and we hope that it will eventually lead to something useful.
SPML and SCIM in midPoint
We see both SPML and SCIM efforts as typical examples of premature standardization. Both SPML and SCIM teams try 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? This is clearly seen in the result of SPMLv2: the XML Schemas that are part of SPML specification are not valid. The schemas will not pass simple XSD validation. SCIM is following a slightly better course than SPML but we are afraid that the results will be roughly the same. Waterfall software development model invariably fails even if it is applied to standardization instead of software.
Our approach to standardization is actually quite the opposite to that of SPML and 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 SPML and SCIM as not very practical solutions. MidPoint tries to be a practical system therefore it is natural that support for both SPML and SCIM is limited:
- MidPoint has a partial support for SPML by the way of SPML connector. There is no support for SPML service on midPoint side. And given the status of SPML there is also no plan to implement such service.
- MidPoint has currently no support for SCIM. There is tentative plan to support SCIM when SCIM matures (if ever). But there are no specific dates yet. However midPoint schema is based on the same specification as standard SCIM schema therefore the two schemas are very similar. And we also believe that other midPoint features are either conceptually compatible with SCIM or form a superset that can be at least partially represented in SCIM. Therefore implementation of basic SCIM support should not be difficult. However, as we see a very limited value in SCIM support there are no specific plans to support it in next few releases. Yet in case any customer/partner is willing to fund the implementation or contribute complete SCIM implementation for midPoint we will gladly provide assistance and squeeze it into the midPoint release plan.
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 ICF 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.