Source code

Apache Syncope

18 February 2020
TL;DR. Give me just a very short summary.

Good intentions.

Apache Syncope is a provisioning system base on relational database repository. The architecture and functionality of Apache Syncope is quite similar to Sun Identity Manager (Sun IDM) in both a positive and negative way. Engineers used to work with Sun IDM will find syncope both familiar and easy to use.

Syncope seems to be something between a product and a framework. It may be well usable in the off-the-shelf form for simple deployments or even slightly complex deployments. But it obviously needs to be extended with Java or workflow code for any complex deployment. Some extensibility is also achieved by using JEXL expressions but most of the flexibility seems to be achieved by programming.

The data model and actually the whole system is tailored to be used as a database application. The data model seems to be mostly fixed (defined by JPA binding), but there are some possibilities to extend it using a run-time schema definition. The schema model is flat, defining string-named attributes that can have values of few primitive data types.

There is only a very basic support for mapping between user and account attributes. Only direct mapping without any transformation is supported. A more complex scenarios can be implemented by using derived attributes and JEXL language. This can work nicely for a simple deployments. But complex deployments will probably fight with a large number of derived attribute definitions. As the derived attribute definitions cannot be tied together with roles or resources to which they (indirectly) apply this can get really messy and difficult to maintain. This suggests that Syncope was designed primarily for simple deployments (for which it can work very well).

Other tricks can be achieved by using virtual attributes. These are taken directly from the resource. This is probably yet another inspiration from Sun IDM where this behavior was a norm. However there is a hidden trap. As the attribute values are not stored locally they become inaccessible when the resource goes offline. In deployments that has 50+ resources it is almost certain that at least one resource will be down. This was a major problem in Sun IDM and it is almost certain that this will also be a problem in Syncope.

There is one more similarity between Sun IDM and Syncope: driving provisioning with a workflow. This makes Syncope quite flexible and can adapt to numerous situation. But it also brings the same drawbacks that caused pain in Sun IDM: difficult error handling, almost impossible transaction-like consistency for resources and consistency issues if there is more than one operation for a single user.

The internal repository is fixed to relational database paradigm, using JPA as an abstraction. It means that Syncope can theoretically operate on top of any SQL database. But it cannot efficiently support NoSQL databases unless the Syncope system architecture undergoes a major re-engineering. This also suggests that Syncope is more suitable for small deployments (up hundreds of thousands identities).

Syncope supports concepts of user, role and membership. Especially the concept of a role membership is a powerful one. It is almost inevitable for full-scale IDM deployment yet it is only implemented by Syncope and midPoint. This a major advantage.

Syncope user interface is a web-based AJAX-style GUI. The interface is not the most beautiful one in the world and it sometimes lacks the ergonomy and ease-of-use. But it is fairly complete and reasonably fast.

Syncope support synchronization users to account and roles to groups. Nothing more. There is no support for organizational structure and it looks like extending Syncope for this purpose is far from trivial.

Syncope has separate (web) console and "core" provisioning engine communicating over a REST interface. These must be deployed as two web applications. Except for that Syncope has almost no internal component structure. There are just three components "core", "console" and "common". While the components are internally divided to packages, except for REST interface there seems to be very little internal interfaces. This will definitely have an negative impact of future maintainability of Syncope-based projects. Syncope team seems to be aware of this and the effort is underway to improve it - although the progress in this cleanup task has been quite slow. Nevertheless it is fair to mention that Syncope is still quite a small project and therefore there is still a chance to clean it up.

The use of REST interface between core and console is also quite unfortunate. It gives a nice separation of layers but in the long run it may be very difficult to maintain. Non-interactive clients and interactive GUI have subtly different requirements for interface functionality, some of which is very difficult to implement using a REST-style interface (e.g. callbacks and inversion of control in general). Also no reasonable support of schema and code generation for REST will make refactoring extremely difficult. This will most likely have a negative impact on Syncope future development. It can also prove to be a performance hit for larger deployments. But what is perhaps the worse consequence is that it makes the GUI programming a real pain. E.g. GUI framework cannot use callbacks and asynchronous notifications which significantly limits the GUI possibilities.

Syncope is a nice small system. But it is not entirely easy to understand how it works. A good documentation is really needed. However the documentation is one of the long-lasting problems of Syncope project. The documentation has somehow improved in a last year or so but it is still very insufficient. The documentation is not complete and not very consistent which makes it quite difficult to read. The lack of documentation makes it almost impossible to use Syncope without a support from the development team.

Syncope is using the ConnId framework as its provisioning workhorse. The ConnId project is a cooperation with three major contributors: Syncope team, Evolveum and ForgeRock. This makes the connectors theoretically interoperable between three systems. Syncope team is the maintainer of ConnId framework. The ConnId framework is based on Sun ICF but it has already fixes several important flaws of the original Sun framework. We highly appreciate that these competing product teams have chosen to cooperate on a common framework.

However it has to be said that Syncope is not using the ConnId framework to its full potential. It looks like the Syncope is hardcoded to only use account and group objectclasses from the very broad spectrum of resource schema. E.g. Syncope cannot work with organization units, non-group entitlement types, etc.

Yet another issue is a provisioning consistency. Similarly to Sun IDM the Syncope seems to have just a basic retry mechanism to handle provisioning failures. This is likely to become a major issue in deployments with large number of resources. Of course, the provisioning consistency handling can theoretically be implemented in workflow. However this is exactly what Sun engineers tried to do and it is a complex and unreliable method.

Overall some of the mechanisms used in Syncope are not bad, but they somehow go only half the way. E.g. Syncope has its own mechanism for authorization which is quite simple. It might be efficient in simple implementations, but it will definitely fail in more complex situations. On the other hand there is quite a complete ARBAC model that Syncope team could have used as a base for their model but they haven't. This quite illustrates the overall trend in Syncope: Syncope seems to be engineering project lead by software developers with very little scientific background. The product could definitely benefit if the team spent a little bit more time in the library.

Syncope is one the smaller projects. But it looks like it serves the purpose for which it was designed. The size of the team is proportional to the project size. What is interesting is that the team is composed from several companies and there are also external contributors. This really demonstrates the power of open source. The core of the team seems to be composed mostly of younger engineers. This fact together with the cross-company cooperation is likely to make Syncope development quite cost-efficient. Therefore we expect that Syncope subscription and services will be relatively affordable.

In fact Syncope is the most open of all the evaluated projects. It has a clear open source strategy. It is a part of Apache Foundation therefore it is almost certain that this strategy will remain unchanged. There are active mailing lists which are openly used to discuss everything about Syncope - including plans and design decisions. This is really unique among all the evaluated projects.

When to use Apache SyncopeWhen not to use Apache Syncope
  • Simple IDM projects that do not require heavy customization.
  • Projects that are prepared to develop custom code in Java or BPMN.
  • Projects with limited budget.
  • Projects that prefer clean open source strategy.
  • Large project that require scalability (1M+ identities).
  • Dynamic environments with many changes that go around the IDM.
  • You need support for organizational structure.
  • You need to synchronize more object types except accounts and groups.
  • You need fine-grained authorization, segregation of duties, GCR or similar advanced features.
What Radovan has to say ...

I'm watching Syncope project almost from its beginning. It had an impressive start by quickly implementing several crucial IDM features, especially workflow integration and GUI. The ideas behind syncope are not bad. But it was obvious very early that Syncope architecture is quite limiting. The Syncope design was perhaps too much influenced by Sun IDM which was the king in 2000s. But it was a dying king. And the world had moved on since then. Many ideas used in Sun IDM are just not good enough any more ...

Nevertheless, I must say that I personally like Syncope. It is my second favorite IDM system on the market (right after midPoint, of course). It is a nice small system for a nice small deployments. And I especially like the energy and dedication of Syncope team. And their openness. And even though we are competing I honestly wish them success.