Source code

CzechIDM by BCV solutions s.r.o.

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


CzechIDM is an simple user provisioning system that was obviously developed as an replacement for Sun IDM. Many principles and also a look and feel are heavily inspired by Sun IDM.

CzechIDM has a very minimal data model for user identity. It is not clear how (and if at all) it can be extended.

CzechIDM supports basic roles and organizational structure. It has support for provisioning roles. The roles can form a simple hierarchy. The roles can enforce attribute values that can either be static (constant) or determined by a rule (BeanShell code). It is not clear how the attribute values from many roles are merged together as the merge options are missing (e.g. the Sun-like "merge", "clear existing"). This can satisfy the requirements of a simple deployments but it likely to cause a lot of trouble for a complicated role structure.

Organizational structure in CzechIDM is a simple tree-like structure. Support for multiple parallel organizational structures seems to be missing. We also haven't discovered any support for organizational structure synchronization.

It looks like most of the CzechIDM flexibility is achieved by using "rules". These are also obviously inspired by Sun IDM. The "rules" are simple pieces of code that are executed at appropriate places in the system. The significant downside is that the "rules" are written in BeanShell. BeanShell is a very outdated language with no significant development activity since 2005. Also similarly to Sun IDM there is not much structure in the "rules". It is hard to figure out which rule is to be used at which place, what are the input parameters and expected output, etc.

User interface of Czech IDM is very simplistic. It has the retro look and feel of 1990s. Also there is a lot of annoying bugs (e.g. page refresh problems) that almost completely destroy the usability of user interface. CzechIDM has a "resource wizard" feature. However it is far from being perfect. Default settings do not work. It takes a lot of trials and errors to configure resource correctly. Documentation is of very little help here and there are no samples that can be used as a starting point.

The system seems to be very slow. Especially the user interface. The response time of a few seconds seems to be normal. All other IDM systems perform significantly better on the same hardware (except for OpenIDM which has no GUI at all, of course).

It looks like CzechIDM contains only an audit log report. Other reports seems to be missing.

CzechIDM has a reasonably good documentation. The user documentation also contains parts of architectural and developer documentation. However, there is no wiki, no documentation regarding development plans, etc. Simply speaking the documentation is not "alive".

CzechIDM contains a workflow engine. However this engine is quite outdated. Unlike all the other evaluated products it uses a proprietary workflow language. Also similarly to Sun IDM the workflow seems to drive all provisioning activities. The advantage of this approach is good flexibility. Every action can be modified using a workflow code. But there is a major drawback: performance. Sun IDM was notorious for its bad performance and limited scalability. And tight workflow integration was one of the reasons. It looks like the workflow in CzechIDM cannot be turned off which makes CzechIDM unsuitable for deployments that require scalability (customer identity management, telco, large public sector deployments, academia, etc.)

CzechIDM data store is based on relational database and it looks like MySQL is the only supported database. CzechIDM is tightly bound to a relational database model. As CzechIDM is also based on Java EE architecture it is very unlikely that CzechIDM can ever support NoSQL databases. Which is a serious obstacle for deployments in telco and cloud.

Authorization model of CzechIDM is also heavily inspired by Sun IDM. Yet it is considerably less powerful. Few basic privileges can be bound to the organizational structure which creates a very crude delegated authorization setup. Everything else is missing. E.g. there is no support for fine-grained authorizations.

CzechIDM is using Sun Identity Connector Framework to connect to the managed systems. This is yet another trace of Sun IDM inspiration. However there are two major issues. Firstly the Sun Identity Connector Framework project is efficiently dead since 2010. Secondly this framework has many design flaws. The Sun ICF framework was a good choice 4-5 years ago. But today this is perhaps the worst possible choice. The three competing IDM product teams started a cooperation to fix the Sun ICF flaws. But CzechIDM team is not part of that effort.

CzechIDM provides a SOAP web service. However it is very very simplistic. It does NOT expose any significant part of CzechIDM functionality. This will make it very difficult to use CzechIDM in integrated architectures (such as SOA). This is really surprising because exposing web service is easy if the internal component structure is correct - especially in Java EE framework which is the foundation of CzechIDM.

Closer look at CzechIDM reveals an interesting fact: it is based on very outdated technologies. It uses a Java EE application framework which is in itself seldom used in a new products - and CzechIDM uses an outdated version of this framework! Also a workflow engine in CzechIDM is outdated. As are the already mentioned BeanShell and ICF framework. CzechIDM runs on a JBoss Application Server that dates back to 2009. But what is perhaps the most severe issues is the user interface. CzechIDM documentation claims that the user interface uses Java Server Faces. But a closer look reveals that it is actually JBoss Seam framework. The problem is that JBoss Seam is a project which was discontinued in 2012. This is significant in two ways. Firstly this lead the user interface of CzechIDM to a dead end. It makes no sense to develop it any more. It has to be completely rewritten - which means that CzechIDM needs a significant investment to be able to simply continue its development. Secondly this indicates that there was no significant update of CzechIDM architecture at least since 2012. This is a serious warning sign.

The source code structure can only be described by one word: messy. There are two build systems used in parallel (Maven and Ant). There are binary JAR files committed into the source code repository. We were not able to build the product from the source code. There are parts that are obviously not finished (e.g. password filter). The whole source code history has only 6 commits which indicates that CzechIDM was either developed in secret or that the team has something to hide. There are no public forums and no commits from developers outside of the core team which suggests that the product has no community. There was absolutely no source code activity for almost 4 months which can indicate that product development is suspended or stopped.

When to use CzechIDMWhen not to use CzechIDM
  • As an example how not to maintain an open source project.
  • If you need good user interface (GUI).
  • If you want to avoid technology debt.
  • If you want need complex organizational structure.
  • If you do not have any BeanShell expertise.
  • If you prefer projects with live communities.
  • If you do not understand Czech language.
  • GRC is required.
What Radovan has to say ...

Logging into CzechIDM reminds me of the good old days of Waveset Lighthouse. This was before Waveset was acquired by Sun and a long time before it all went to a death march in Larry Elison's kingdom. CzechIDM is almost perfect reincarnation of SunIDM. It has most of the good things that we liked about SunIDM. The downside is that it also has almost all of the drawbacks.

CzehcIDM has almost everything that an IDM systems needs to have: connectors, users, organizational structure, roles, reports, user interface. But it implements the very minimum that it would pass for. Every feature is at its very basic. CzechIDM is not impressive in any way. It is not innovative in any way. It looks like it is built to be "just enough" to be deployable. However it ends up to be almost completely useless.

It takes all the running you can do to keep in the same place. But it looks like CzechIDM team was not exactly running during the last couple of years. CzechIDM has fallen behind. It is clearly not ready for the prime time. And given the development history it is very unlikely that it will ever be ready.