Source code

ForgeRock OpenIDM

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

It is not entirely open and it is not entirely IDM.

OpenIDM is a part of ForgeRock's I3 suite. The version 3 of OpenIDM is a very flexible provisioning framework. It provides a basic identity management functionality that can be extended using a custom scripting code. However it is obviously expected that the deployment team will develop most of the functionality needed for a comprehensive IDM deployment.

OpenIDM is heavily based on JSON, providing RESTful interfaces that is used for most of the configuration and control. The internal repository is pluggable providing support for relational database and (non-production) support for OrientDB noSQL database. All four major databases are supported.

OpenIDM policies are very flexible, expressed partially in a declarative fashion and partially in a form of JavaScript/Groovy code. The code is used to validate the values of individual attributes. While this is excellent solution for validation, it is almost useless to efficiently generate a value. E.g. OpenIDM cannot easily generate a password that complies with the configured policies even though it knowns all the policies.

OpenIDM as an IDM system is extremely flexible. Excellent extensibility is achieved by writing a custom JavaScript or Groovy code - which is necessary for all non-trivial OpenIDM deployments. In fact OpenIDM seems to be a framework of loosely coupled and partially integrated IDM functions. The solution needs to be integrated by the deployment engineer to take the final shape. This places a considerable burden on the deployment engineer both in the form of deployment cost and the required skill of the engineers. However this approach makes OpenIDM applicable even in situation in which no other IDM system could be applied.

The OpenIDM approach is efficiently moving responsibility for some of the complex IDM algorithms to the deployer (role hierarchy computation, SoD, distributed consistency, entitlements, full delegated administration, advanced error handling, handling of offline resource, data caching, etc.) The deployment engineers need to develop advanced algorithms themselves. This needs to taken into account for complex solutions that need to create, test, document and (especially) maintain a complex JavaScript code-base.

OpenIDM does not define the structure of objects stored in its repository. Although some default definitions are provided the possibilities are almost endless. It is important to realize that this is both advantage and a disadvantage. This approach provides excellent flexibility. But it makes it very difficult to create components that require more rigid structures. E.g. it is very hard to create good user interfaces for these flexible systems. This may be one of the reasons why OpenIDM does not have any practical GUI. It is also very difficult to create analytical systems such as role mining on top of such flexible data. The schema also needs to be invented for each individual deployment. OpenIDM transfers the burden of schema definition and integration from the product to the deployer. Therefore it makes OpenIDM deployments much more costly than the deployment of any other evaluated system.

How much IDM is OpenIDM?

OpenIDM is a very generic and flexible product. This is without any doubt a great benefit. However this also has a dark side. Most functionality of OpenIDM deals with generic concepts such as data storage, task management, REST interfacing, etc. There is very little code which is specific to identity management deployments. This fact is very obvious from the source code analysis. However this means that most of the IDM functionality must be developed specifically for each and every deployment in a form of custom code.

Although OpenIDM can theoretically work with any kind of objects there is one critical flaw. OpenIDM does not understand how these objects relate to each other. Perhaps the best way to explain this is to show the difference between midPoint and OpenIDM. MidPoint has a fixed (but extensible) base schema for user, role and entitlement. As the base schema is fixed midPoint knows that roles can be assigned to users and that entitlements are the reflection of roles on the target system (LDAP group is an example of entitlement). And as midPoint knows the relation between object types it can be easily configured to automatically create an LDAP group for each new IDM role. MidPoint can also automatically add user account to a group when user gets the role. As this is all declarative specification midPoint can have a user interface that supports this functionality by default - without any need to modify user interface code. But OpenIDM is very different. Although OpenIDM can mostly do the same things it cannot be configured to do it. It has to be programmed. Which is much harder. But even more importantly this also means that OpenIDM cannot have an efficient user interface to support this functionality. Configuration can be easily displayed in user interface. But it is almost impossible to intuitively display a programmed algorithm. The OpenIDM user interface code needs to be modified especially for each and every deployment. This makes OpenIDM deployment a very difficult and costly endeavor.

OpenIDM has no built-in support for organizational structure. This is major obstacle for IDM deployments. Organizational structure is a vital part of identity especially in enterprises, public sector and academia. Organizational structure is also a crucial part of delegated administration. OpenIDM data model is flexible and it can be extended. But extending it to support a tree-like structure in an efficient and scalable way is a major feat. It is likely to ruin the feasibility of the entire IDM project. What is even worse it looks like the OpenIDM team does not even plan to support organizational structure. It is not on the roadmap, the feature request in their tracking system is still marked as "won't fix" and the mailing list questions regarding organizational structure are left without any response. This is a critical issue for IDM deployments.

OpenIDM RBAC implementation is extremely simplistic. In fact it is questionable if it is really a complete RBAC implementation. E.g. support for role hierarchy seems to be missing. The support for provisioning roles finally appeared in OpenIDM 3.0. But it looks like it is mostly just a "placeholder" and the feature itself is very limited in functionality. It looks like it allows only a simple static attribute values to be enforced by the role, there is no simple way to support entitlements (such as LDAP groups), etc. It looks like OpenIDM still needs to use hacks in the connector code to practically support at least some kind of group membership. There is a very basic support for role conditions. But it is not generic and it has very limited utility.

The RBAC support in OpenIDM seems to be heavily inspired by the design of OpenIDM 1.x code (which was entirely dropped). However the team obviously haven't learned all the lessons of OpenIDM 1.x and they omitted crucial elements. E.g. the data model of OpenIDM 3.x cannot easily support parametric roles, temporary role assignments, etc. Actually the OpenIDM 1.x had a data model suitable for a more advanced RBAC features than the current data model of OpenIDMv3. We expect that the OpenIDM RBAC system will need to be significantly re-engineered in next versions of OpenIDM.

OpenIDM is the only product from all the evaluated projects that does not have a practical administration user interface. The GUI that OpenIDM provides is more-or-less just a very simple prototype that does not even works with some of the samples that OpenIDM provides. Such GUI is useless for any serious practical use. It has to be heavily modified for every deployment project. Or it has to be written from scratch. This will surely make most OpenIDM deployment projects very expensive.

But there is even a more important concern. Given the OpenIDM nature and flexibility it is questionable whether any comprehensive administration GUI can ever be developed. Everything in OpenIDM is flexible and programmable. Creating GUI for this kind of system is extremely demanding task. The OpenIDM architecture was obviously not designed for visualization. And even if such GUI could be implemented this is most likely to be a major development task that will undoubtedly take at least several years of heavy development effort. Therefore we have to conclude that it is extremely unlikely that OpenIDM will have a comprehensive administration GUI in any foreseeable future.

OpenIDM is using their own version of ConnId framework. The ConnId project is a cooperation with three major contributors: Apache Syncope team, Evolveum and ForgeRock. This makes the connectors theoretically interoperable between three systems. We consider this to be a very positive development. The ConnId framework is based on Sun ICF but it has already fixes several important flaws of the original Sun framework. Even though OpenIDM is using the ConnId framework it has its own connectors developed in OpenICF project. The OpenICF project is lead by ForgeRock and it includes partner contributions. However, Evolveum has recently left the OpenICF project due to cooperation issues. Evolveum was the second most active contributor to OpenICF. This leaves OpenICF project without any major contributors except for ForgeRock itself.

OpenIDM includes workflow engine. Similarly to other projects this is Activiti engine. The workflow is not an integral part of the product and it can be turned off. This is a benefit for lightweight and scalable solutions.

OpenIDM has a data storage abstraction layer. Therefore it can store data in relational databases but it can use also other data stores such as NoSQL databases. This is crucial feature for scalable deployments such a cloud or telco deployments.

OpenIDM has a REST interface which is mostly complete. It is used as a primary system interface and it looks like the entire system was wrapped around it. This is similar to the way in which OpenIAM is wrapped around ESB. And similarly to OpenIAM this approach could backfire. REST is currently fashionable but it is not without problems. The WWW architecture is flawed and RESTful interfaces must work around many issues. Which means that even OpenIDM REST interface is not entirely RESTful. E.g. roles are resources but they are not referred to by URL, using _action=create instead of PUT, etc. Actually many things are just RPC over HTTP and not REST. E.g. reconciliation is started by invoking _action=recon and not by creating a WWW resource. Adapting the entire system architecture to match a fashionable buzzword can be extremely dangerous.

OpenIDM infrastructure is also quite tightly integrated with OSGi framework. OSGi is very flexible but it has quite a steep learning curve. Although OSGi is not exposed to the user, system administrator needs to deal with it.

Similarly to other aspects of OpenIDM the authorization model is also bound to the REST interface. Binding authorization to a primary system interface is a good first step. But it is not enough. Fine-grained authorization or any in-depth authorization seems to be completely missing. Of course, given OpenIDM nature everything can be developed. But similarly to other security features it is extremely difficult to do correctly and in a secure fashion. E.g. a proper fine-grained authorization mechanism must rewrite search queries and post-process search results. It also has to be implemented on several layers deep inside the system, e.g. to distinguish between authorization to change account attribute directly and authorization to change it indirectly by using a policy (mapping). Support for this kind of authorization-in-depth seems to be completely missing in OpenIDM. All the authorization is only focuses on the surface which makes the system potentially vulnerable. This authorization mechanism may prove very problematic especially for cloud systems as it will be a significant challenge to implement a proper in-depth tenant isolation.

A considerable amount of custom development and scripting is required to run OpenIDM. This is very difficult to do without appropriate tools. We would expect a programming framework such as OpenIDM would natively integrate with an Integrated Development Environment (IDE) product. However we have not found any guide or any other documentation regarding this topic. Therefore our best guess is that OpenIDM is simply not used for complex IDM deployments at all.

The authors of OpenIDM claim that OpenIDM is a Java-based system. However significant amount of OpenIDM functionality is developed in JavaScript or Groovy. In fact it can be hardly imaginable that OpenIDM can provide even the most basic function without these scripting parts. Therefore we believe that OpenIDM is not a Java-based system any more and it in fact much closer to systems written in scripting languages such as PHP. This makes OpenIDM a good choice for prototyping and experimentation. But it makes it a poor choice for long-term operation. Identity Management deployment requires complex algorithms and policies that are extremely difficult to maintain in semi-formal scripting form. We strongly believe that complex OpenIDM deployments will eventually turn into maintenance nightmares.

The OpenIDM documentation is in a very good shape. It has professional structure and excellent technical writing style. The installation and administration procedures are reasonably simple and well documented. However the architectural documentation is almost entirely missing. There is only a single block diagram which is mostly suitable for sales presentations. But a technical architectural description is very weak.

How much open is OpenIDM?

The source code of OpenIDM is apparently following the open source model. However, there are major issues. The binary releases cannot be freely downloaded. Commercial subscription is required to use the binaries (we have used OpenIDM version compiled from the source code for the purpose of this evaluation). The contribution process is also quite complex requiring a mandatory code review to contribute even the most trivial fix. OpenIDM is the only project from all the evaluated projects that is still using centralized version control system (Subversion). This makes contributions very difficult as for any non-trivial contribution the contributor needs to request a development branch, the request to merge it back and also needs to pass the mandatory code review. The combination of these factors is a deadly mix that efficiently kills most of the contributions from the community. (For the record: Code reviews are a good thing. But they need to be used in an appropriate way otherwise they can kill development efficiency.)

The positive sign is that OpenIDM has non-negligible user community. Mailing list are relatively active. However there are many questions on the mailing lists that are either not publicly answered or are "routed" to the sales department. This may somehow suggest how ForgeRock plans to deal with the community. The upside is that there is a public wiki and issue tracking system. However the wiki content is quite outdated. It mostly refers to OpenIDM version 2.

Actual source code of the system is in a good shape. It is reasonably structured and it builds cleanly (even in the development version). The development team is relatively large. According to the source code history at least two senior developers that started the project are no longer participating which may be a warning sign.

The interesting fact is that OpenIDM source code is one of the smallest among all the evaluated products while at the same the the development team is by far the largest one. The size of the team may suggest that the OpenIDM subscription are likely to be expensive and therefore it can raise questions about price/performance ratio of OpenIDM.

When to use OpenIDMWhen not to use OpenIDM
  • Project that require extreme customization.
  • Projects that require scalability (1M+ identities).
  • If you have in-house development team (JavaScript or Groovy).
  • If you have a very generous project budget.
  • In the enterprise environment.
  • You need user interface (GUI).
  • You need good RBAC support.
  • You need support for organizational structure.
  • You have no programming experience.
  • You need integration over SOAP.
  • GRC is required.
  • You have limited budget.
What Radovan has to say ...

OpenIDM is the smallest of all the evaluated systems. But it is probably the most expensive of all. It has a huge international development team. The cost of such team must inevitably be reflected to the subscription price. But there is different reason why OpenIDM deployment is going to be expensive. OpenIDM needs to be extended with a huge amount of custom code to make it practical. This is likely to drive many IDM projects high over the budget.

And there is yet another critical deficiency of OpenIDM. It does not have a practical administration GUI. You can perhaps thing that this is not a big issue and that the ForgeRock team can quickly develop the rich GUI. But this is actually very unlikely to happen. OpenIDM 3.0 had no administration GUI at all. The administration of OpenIDM 3.1 does provide only the very basic features. The development obviously proceeds quite slowly.

I have a very precise records from midPoint development. It took 6739 man-hours to develop midPoint GUI (excluding testing). MidPoint is designed from the day one for good GUI support. And midPoint development team is without any doubt the most efficient of all the evaluated teams. But OpenIDM is entirely different in these aspects. OpenIDM GUI will require several times more effort to be developed. This means it will take several long years before OpenIDM GUI becomes reasonably complete and usable.