Source code

OpenIAM IDM Community Edition

21 March 2018
TL;DR. Give me just a very short summary.

Over-engineered and confusing.

OpenIAM is a IAM solution that has both the IDM (provisioning) and AM parts integrated together. Which makes it quite unique among all the evaluated products. Another aspect that makes OpenIAM unique is its architecture. OpenIAM is tightly integrated with an enterprise service bus (ESB). The connectors are just ESB services.

OpenIAM features are obviously designed with enterprise environment in mind. It support management of users, roles, groups, resources and also organizational structure management. However these concepts are both simple and complex at the same time. There are roles, groups, resources and organizations. Each of them works differently and it is not clear when to use which one. However their functionality is mostly the same. But there is almost no unifying principle. This unnecessarily complicates the system. On the other hand the roles and resources have very limited capabilities when it comes to provisioning. The role/resource can only enforce static attribute values. It is almost certain that this will directly lead to a role explosion problem.

Is OpenIAM really open source?

There are doubts about how open the OpenIAM really is. It is not entirely clear what license applies to OpenIAM distribution. Crucial parts of the system are not publicly available in source code form. We have considered to leave the OpenIAM out of this evaluation completely. But finally we have decided to include it simply for the sake of completeness. However we recommend a great caution when using OpenIAM. Perhaps the best approach would be to contact OpenIAM authors and ask for an explanation.

The data model of organizational structure is very "relational". If you are looking for a nice tree-like organizational structure you will probably disappointed. According to the documentation OpenIAM can synchronize organizational structure. However the actual implementation is a Groovy script that simply copies data directly from the database to the managed system. It does not use the connector and it does not share the managed system configuration. It is almost certain that this will become a maintenance nightmare.

The nice thing about OpenIAM is that it supports management of group membership out of the box. This is still a rare feature in IDM products. The documentation states that OpenIAM has capability to synchronize groups and roles but we were not able to confirm this claim. We can only guess that this ability is similar to the ability to synchronize organizational structure.

OpenIAM contains a workflow engine. Similarly to most other evaluated systems this engine is implemented by Activiti. Therefore the workflow engine has mostly the same capabilities as the other evaluated systems. However there is one aspect that is different. It looks like OpenIAM is using workflow engine for all operations. Each operation is routed through workflow. This is idea which obviously originated in Waveset and was one of the basic characteristics of SunIDM. It is also used by CzechIDM and Syncope that are obviously heavily inspired by SunIDM. The advantage of this approach is good flexibility. Every action can be modified using a workflow code. But there is a major drawback: performance. SunIDM was notorious for its bad performance and limited scalability. And tight workflow integration was one of the reasons. While Syncope has an option how to turn off the workflow OpenIAM does not seem to support this option. Which makes OpenIAM not suitable for deployments that require scalability (customer identity management, telco, large public sector deployments, academia, etc.)

OpenIAM supports very basic authorization model. Administrator can grant authorizations to specific parts of user interface ("menus"). There seems to be very little authorization code beyond the user interface. This is only feasible for very simple deployments.

Overall OpenIAM has only basic built-in models for RBAC, organizational structure, reconciliation and synchronization. Anything that does not fit into that model requires programming. Quite complex programming. Reconciliation and synchronization usually need programming as well. Therefore most OpenIAM deployment projects need Java or Groovy developer as an important member of the deployment team.

OpenIAM data store is based on relational database. It supports MySQL, MariaDB, Microsoft SQL and Oracle. Support for PostgreSQL is missing. OpenIAM seems to be tightly bound to a relational database model. When we also consider it's architecture based on ESB and very slow development we have to conclude that it is extremely unlikely that OpenIAM can ever support NoSQL databases. Which limits its scalability even more.

OpenIAM provides SOAP and REST interfaces. While the SOAP interface seems to be fairly complete the REST interface seems to be just a placeholder. It provides only a very small subset of functionality which makes it practically useless.

Although OpenIAM claims to have excellent architecture the internal component structure of OpenIAM is not very readable. The essential documentation is also missing. Therefore this claim cannot be verified. The source code itself also leaves much to be desired. It obviously uses the Java 6 style which dates back to 2006. The source code also contains binary JAR files which is generally considered to be a bad practice.

The heavyweight foundation of OpenIAM takes its toll. OpenIAM has a very high resource consumption. The hardware resources needed to run OpenIAM during our tests were approximately three times higher than we needed for any other evaluated system.

OpenIAM has quite good user documentation. There are step-by-step guides, screenshots and videos. However it is surprising sparse on pictures that describe the principles. Also there is almost no architectural and developer documentation. There source code comments are also mostly missing. Contributing to this project is most likely going to be very difficult.

OpenIAM open source strategy is not entirely clear. The product used to have open source and closed source parts (i.e. "open core" model). This is further emphasized by the fact that the downloadable part of OpenIAM contains the acronym CE which usually stays for "Community Edition". However we could not find any information about this on the website any more. The product distribution is also NOT freely downloadable and requires a registration - which is a very bad practice for a project that claims to be open source. What is even worse if the fact that we could not find proper licensing information neither on the website nor in the source code. Most source code files do not have any licensing header. A few source code files have LGPL header, however the pom.xml file refers to Apache license. Project information on shows GPL3 as license. We understood the statement in pom.xml to apply to the entire project therefore we assumed Apache license for OpenIAM for the purpose of this evaluation. However we are afraid that this uncertainty may cause legal concerns over the use of OpenIAM. But what is perhaps the most severe problem is the lack of connector code. The source code of the connectors is nowhere to be found. As OpenIAM uses proprietary connectors the whole system is almost completely useless without them. Therefore we have to recommend to stay on the safe side and do NOT use OpenIAM at all unless you have a written contract with OpenIAM copyright holders.

OpenIAM project seems to have a very small team and the vast majority of the product is mostly a work of just a single developer. Which raises a serious concerns about project continuity. The upside is that the OpenIAM code-base has contributors that looks like they are not directly affiliated with OpenIAM company. However the significant downside is that the public forums are almost empty. This suggest that the there is almost no public interest in OpenIAM except for OpenIAM partners and customers. This is a significant warning sign suggested that OpenIAM information is kept inside the team and it is not publically communicated.

When to use OpenIAM IDMWhen not to use OpenIAM IDM
  • If you already have good experience with ESB-based architectures.
  • If you need recertification out-of-the-box.
  • Mid-sized or large projects that require scalability (100K+ identities).
  • You have limited hardware resources.
  • Cloud environments that need multi-tenancy support.
  • Fine-grained authorization is required.
  • You prefer open source projects.
  • You do not have written agreement with OpenIAM authors.
What Radovan has to say ...

The OpenIAM website claims that the OpenIAM architecture is "second to none". This is a very true statement in its own way. No other evaluated product has such an over-engineered architecture. ESB inside IDM is a very bad idea. I know that for sure. I was there ...

In 2010 I was part of the OpenIDM v1 development team. We have tried to use the same idea as OpenIAM is using now: build OpenIDM around ESB. The whole team tried to work on that for more than a year. But the idea proved to be a bad one. It was too complex and too fragile. It slowed us down instead of helping us to achieve our primary goal. We had to focus on ESB rather than investing time and effort to solve IDM problems. These are exactly the symptoms that I see in OpenIAM project now.

The ESB concept was eventually dropped both by the OpenIDM team and the midPoint team. The OpenIAM is the only project that still struggles on ...