Open Source Identity Management Systems
Introduction
The era when commercial closed source IDM products ruled the market is nearly over. The beginning of an end of this era was when Oracle demolished Sun IDM. Sun IDM was a popular product and this decision had a hard impact on a lot of Sun customers. The customers are starting to realize that no vendor, not even the biggest one, is stable enough to guarantee protection of their investment in IDM solution. This is partly caused by the fact that most IDM deployments are significantly customized and that there is no easy migration path from one product to the other. "Migration" of IDM deployment in fact means re-implementation from the ground up. Open source solutions provide better protection of investment - ability to stay with the same product even if "vendor" is dead. That was clearly demonstrated when ForgeRock took over OpenSSO product that Oracle abandoned. That was the first major case of this phenomenon but it is unlikely that it was the last one.
When a tree falls in the forest new trees rapidly grow to take its place. We can clearly see this in the field of identity management. New projects grow up to fill in the gap in the market. Among these there are few promising open source projects. However, it may be difficult for an IDM expert to see inside these projects. As our expertise is both in the field of IDM and software architecture we can see inside and we attempt to understand. Therefore we have compiled this list of open source IDM projects with a short summary of the features as we understand them in a hope that it will help other to navigate the currents of this emerging IDM subfield.
The evaluation is based on technical and especially architectural properties of the systems. Business properties (such as availability and pricing of support) are not considered. However, we haven't analyzed the source code in depth, we have only had a "quick look" at the code and evaluated mostly system architecture and design. Therefore the evaluation does not reflect the amount of bugs, visibility (logging, diagnostic output) or similar characteristics.
All the open source IDM systems are relatively new. While it is interesting to see what the system can do right now it is even more interesting to see what is the perspective in few years when they mature. As we are looking for a long-term solution both for our business (IDM deployments) and for our customers, we have focused our evaluation to the properties that can hint how the system will evolve. Therefore we focus on system architecture, constraints and also development speed.
The opinions are our own. Although we have tried to maintain a neutral point of view, we cannot guarantee that we have succeed. Some projects are more transparent than others therefore we may have misunderstood some concepts. Also, we are describing the projects from the point of view with respect to IDM deployment projects that we have done in the past. Therefore the suitability of described technologies for other project may vary. We also were (and are) involved in some of the described project, which may have case a bias in the evaluation (see "About nLight" below).
The products are listed in alphabetical order. Only open source provisioning systems are listed. Other types of IDM systems my be added in the future. Any questions and comments are more than welcome (contact page).
Apache Syncope
| Homepage: | syncope.apache.org |
|---|---|
| Ohloh: | syncope |
| License: | Apache License, Version 2.0 |
| Backing: | Tirasa |
| Core technologies: | Java (JEE), Spring |
| Connector framework: | ConnId (Sun Identity Connector Framework fork) |
| Identity repository: | Relational database only (JPA) |
| Workflow engine: | Activiti (pluggable) |
| Last updated: | March 2013 (version 1.0.6) |
| Short summary: | Simplistic but interesting product. Seems to be quite practical. |
Apache Syncope is a provisioning system base on relational database repository. The architecture and functionality of Apache Syncope is very 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 slightly complex deployment. Some extensibility is also achieved by using JEXL expressions but most of the extensibility seems to be achieved by programming. Syncope uses the same principle as Sun IDM: 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 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 are only a very basic support for mapping between user and account attributes. While a more complex scenarios can be implemented by using derived attributes the Syncope approach seems to be much less powerful than that of midPoint or OpenIDM. It looks like the data model does not account for ability to locally copy account information to the IDM repository and therefore provide ability for off-line operations and efficient reports (which was one of the Achilles' heels of Sun/Waveset IDM).
The internal repository is fixed to relational database paradigm, using JPA as an abstraction. The fixation of the code to JPA seems to be quite unfortunate. JPA is a leaky abstraction that is difficult to fit even to the major databases. While basic operations work well, there are details that needs to be addressed for concurrency control, atomicity, binary data, etc. In Syncope there is danger that such details will leak to the core Syncope code and therefore make it very difficult to maintain.
Syncope supports concepts of user, role and membership. Especially the concept of a role membership is a powerful one and is almost inevitable for full-scale IDM deployment. In this Syncope is more like midPoint (in which it is called "assignment") and unlike OpenIDM which does not have any such concept out of the box. Syncope seems to have no support for organizational structure (but it is planned in a form of "realms").
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 user interface is a web-based AJAX-style GUI. While the interface is not the most beautiful one in the world and it lacks the ergonomy and ease-of-use it is perhaps the most complete GUI in all the evaluated systems.
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. However, Syncope team seems to be aware of this and the effort is underway to improve it.
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. This is planned to be improved in the next version by using JAX-RS, but the fundamental drawback of the current REST technology just cannot be easily fixed.
The documentation is insufficient. There is not enough documentation and it is difficult to read. It is more like a set of random notes than a consistent documentation. The lack of documentation makes it almost impossible to use Syncope without a support from the development team. It is also slightly difficult to get started with the project. There is no binary distribution and the product needs to be built from maven archetype (which may not be that difficult assuming some experience with Maven). Also the need of deploying it as two separate WARs introduces unnecessary additional complexity, especially for simpler deployments.
Syncope uses ConnId framework as its provisioning workhorse. This is fork of Sun Identity Connector Framework with some improvements. While this effort is not yet coordinated with other projects (which are cooperating on OpenICF project) the possibility of merging these projects are being discusses right now.
According to source code repository Syncope development started in mid-2010. The development speed was moderate to slow but it has slightly increased recently (approx. 800 commits per year). The code-base is relatively small (approx. 150 KLOC)
Changes in last 6 months: Syncope is an Apache project now. Except for that there were some improvements and bugfixes in the code but only a very few new features.
When to use Syncope: Simple IDM projects that either do not require heavy customization or the engineers are happy to customize it in Java and BPMN. Direct support from the development team will most likely be desperately needed as there is almost no documentation.
When NOT to use Syncope: Projects that require heavy customizations. Also if consistency is an issue then Syncope might not be the right choice. We also do not recommend using Syncope if there is very little software development experience in the deployment team (Java and BPMN are the most likely skills that will be required during the project).
Our conclusion: Syncope had an impressive start by quickly implementing several crucial IDM features, especially workflow integration and GUI. But from the beginning we were afraid about the inherent limitations that are "under the hood". The ideas in Syncope are not bad, but some of the mechanisms are too simplistic and not systemic. Syncope is a pure engineering and software development project. Unlike midPoint and OpenIDM, Syncope seems to be reaching for the low-hanging fruit and mostly follow the design and architecture of Sun IDM. Engineers that were used to work with Sun IDM will most likely enjoy using Syncope as well. But they need to be prepared to suffer almost the same architectural issues that plagued Sun IDM.
MidPoint
| Homepage: | midpoint.evolveum.com |
|---|---|
| Ohloh: | midPoint |
| License: | CDDL version 1.0 |
| Backing: | Evolveum |
| Core technologies: | Java (Spring), XML, Prism, Wicket |
| Connector framework: | OpenICF (Sun Identity Connector Framework fork) |
| Identity repository: | Relational database (pluggable) |
| Workflow engine: | Activiti (pre-release) |
| Last updated: | March 2013 (version 2.1.1) |
| Short summary: | Innovative IDM product aimed at cost-efficient IDM deployments. There is much under the hood that is not obvious on the outside. |
MidPoint is a pragmatic provisioning system. It has ambitions to become a complete provisioning product with features comparable with commercial offering but exceeding the commercial software in quality. The primary goal of midPoint is efficient deployment of IDM solutions and everything in midPoint is designed to support that goal. MidPoint supports many common-case scenarios directly in the product with no need to re-develop the solution for each deployment again and again. Therefore a deployment engineer needs only to configure and customize the product and does not need to invest time in writing, testing and debugging the code for features that are used in almost all IDM deployments.
MidPoint has an extensible Java-based provisioning engine working on top of database repository and a connector framework. MidPoint is based on older, proven technologies for reliability, new technologies are gradually introduced to the project as needed. What is really innovative in midPoint is not the technological platform. The innovative part is the provisioning engine and customizable logic which is really pushing the boundaries of current technology. MidPoint core goes beyond engineering into the scientific research. Even though midPoint development team is relatively small it includes two PhDs and significant portion of the team actively works on research projects. That is definitely seen in the product architecture and quality, both positive and negative. The positive aspect is that midPoint has a clean architecture, good component design and separation which gives very good expectations about future development and maintainability. Basic design principles are backed by an UML model. New concepts and features are tested in prototypes before they become part of the product. However, doing things the right way takes a bit longer than doing the basic simplistic implementations.
MidPoint is extensible by scripting expressions (currently Groovy, ECMAScript/JavaScript and XPath2, similar principle to Sun/Waveset IDM but much more powerful) or by writing custom Java code. Support for workflows using Activiti BPM is provided in experimental quality is being tested for production use right now. Workflow integration in midPoint goes slightly deeper than that of OpenIDM or Syncope therefore it takes longer to design, implement and test. Therefore it is still in the testing pre-release stage (full production expected in the next release). Even though midPoint is designed with extensibility in mind, midPoint extensibility beyond usual IDM user-cases is currently slightly limited when compared to OpenIDM or even Syncope. However, midPoint is still an open source product and therefore even the extreme customizations can be done by modifying the source code (which is well structured and documented).
midPoint supports concept of user, account, role and organizational unit. It also support quite powerful concept of assignment that can parametrize relation between user and role (or organization unit). RBAC mechanism in midPoint is very advanced and when coupled with the assignment mechanism it goes well beyond the usual industry standard.
MidPoint has integral web-base administration interface. Although the interface does not cover all the features of the backend it is continually updated in each new version. Most of the configuration is now done by importing XML files. There is almost no end-user UI. The motivation is that end-user UI is frequently heavily customized or completely reworked as a custom application. Therefore midPoint development team prefers core functionalities over GUI improvements. However, end-user GUI is planned as a development of administration UI working under a concept of fine-grained authorizations and delegated administration (work in progress).
MidPoint is using OpenICF provisioning framework which is a fork of Sun Identity Connector Framework. It is the same framework that OpenIDM uses. Evolveum and ForgeRock cooperate on OpenICF development.
MidPoint is completely based on concept of relative changes. This delta-based mechanism is very powerful especially in integration scenarios as it usually provides good consistency without the need for locking or manual corrections. However, using this novel approach slightly complicates the system and it takes some time to get used to it.
MidPoint documentation is average. There is architectural documentation, administration and deployment documentation. Although some support from the midPoint team is most likely to be required to fully appreciate midPoint qualities.
MidPoint code is partially based on OpenIDMv1 code dating back to early 2010. MidPoint development is rapid (over 2000 commits in a year). The code-base is relatively rich (approx. 250 KLOC)
Changes in last 6 months: There were two releases of midPoint in last 6 months. One of them was a full production release with enterprise-class scalability and build-in high-availability mechanisms, the other was a maintenance release. Lots of new features were introduced.
When to use midPoint: IDM deployment that are mostly common-case scenarios and need to be cost-efficient. Deployments that require long-term maintainability while keeping the overall cost reasonable.
When NOT to use midPoint: Projects that are far outside the range of usual IDM solutions. Solutions that require a full-featured GUI out of the box.
Our conclusion: MidPoint is our IDM product of choice. The quality and efficiency of IDM deployments is crucial for our style of work, therefore we need product that supports that. MidPoint team has the ambition and demonstrably also the skill to make midPoint the most advanced IDM product in the open source field. And even beyond.
Full disclosure: nLight is taking part in midPoint development. See "About nLight" below.
OpenIAM Identity Manager
| Homepage: | www.openiam.org |
|---|---|
| Ohloh: | openiam-idm |
| License: | The Apache Software License, Version 2.0 (according to pom.xml in the source code), GPLv3 (according to the website) |
| Backing: | OpenIAM |
| Core technologies: | Java, SOA |
| Connector framework: | SPML (most likely) |
| Identity repository: | unknown |
| Last updated: | June 2012 (unknown version) |
| Note: | This entry is no longer maintained (see below) |
OpenIAM seems to be one of oldest open source provisioning systems. It seems to be based on SOA architecture, but the technical details are not clear. The documentation is a complex labyrinth and it is almost impossible to find the source code. According to the available documentation the connectors are SPML-based which we consider to be a major disadvantage. Extensibility properties are unknown. It seems that there is a open source version ("Community Edition") that has only a subset of all the features. This seems to be almost unusable for any production environment because some essential features are missing (e.g. high availability). Therefore it is questionable if this products can even be considered open source. The development speed seems to be slow, approx. 300 subversion commits in 3 years.
Note: OpenIAM source code repository seems not to be available to public. Although the project claims that it is available under GPLv3 license this obviously only applies to the community edition. As the source code is not available we no longer consider this to be a pure open source product and therefore will no longer maintain this listing.
Our conclusion: We see OpenIAM as not really a transparent project. We found it difficult to familiarize with the way how OpenIAM works and is developed. Also, the architecture internally based on SOA may be a major disadvantage. Similar approach was attempted in OpenIDMv1 but it was proved to be unpractical - which led to OpenIDMv2 and midPoint development branches, neither of which is using SOA internally. SOA, SPML and other architectural characteristics of OpenIAM together with slow development speed render OpenIAM a risky choice.
OpenIDM
| Homepage: | openidm.forgerock.org |
|---|---|
| Ohloh: | openidm |
| License: | CDDL |
| Backing: | ForgeRock |
| Core technologies: | Java (OSGi), JSON, JavaScript |
| Connector framework: | OpenICF (Sun Identity Connector Framework fork) |
| Identity repository: | Flexible, currently relational database and (experimental) document database |
| Workflow engine: | Activiti |
| Last updated: | March 2013 (version 2.1) |
| Short summary: | Framework for developing IDM deployments. |
OpenIDM is a part of ForgeRock's I3 suite. The version 2 of OpenIDM is a very flexible provisioning framework. It is basically a set of semi-integrated components that can be put together using declarative statements and custom scripting code. OpenIDM is not meant to be deployed out-of-the-box. It expects that some parts of IDM functionality will be provided by the deployment team.
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 but PostgreSQL has only a "community" support and it is not endorsed for production use.
OpenIDM has a very minimal user interface. It provides only very basic and minimal functionality from end-user perspective. There is no administration GUI. But as OpenIDM configuration requires fair amount of scripting (usually JavaScript) it seems that using an IDE will be required to support efficient development of custom code.
There is still no off-the-shelf support for RBAC or any other advanced access control model for provisioning. While this can be partially implemented in the JavaScript code, expected effort to implement support for hierarchical RBAC is most likely beyond the reach of many IDM deployments. Similar situation applies to organizational structure support and therefore also delegated administration. This may be an obstacle for comprehensive IDM deployments. OpenIDM also has no concept of membership or assignment. While it also can be developed as a custom code it might be quite complex.
OpenIDM is using OpenICF provisioning framework. OpenICF is a fork of Sun Identity Connector Framework. It is maintained by ForgeRock and developed in cooperation with partners (including Evolveum). This is the same framework used by midPoint.
OpenIDM policies are also very flexible, expressed partially in a declarative fashion and partially in a form of JavaScript 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 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 infrastructure is 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. OpenIDM architecture seems to be resource-oriented (a.k.a. "RESTful") on the outside and service-based on the inside. While this resonates well with the latest technological buzz it is not ideal approach for data-intensive integration scenarios such as IDM.
The OpenIDM documentation is in a very good shape. The installation procedures are reasonably simple and well documented. Also the administration documentation is sufficient and it is very good for a young open-source project.
The source code of OpenIDM is following the open source model. However, ForgeRock business model has slightly changed recently. Commercial subscription is required to use binaries that were compiled and tested by ForgeRock.
The source code of OpenIDMv2 is still very fresh (originated in mid 2011) and the project is built with considerable amount of technologies that are not very common in IDM field, which can be both an advantage and a risk. The development speed seems to be moderate (approx. 1000 commits in a year). The code-base is difficult to asses. While the overall size of the code-base is approx. 220 KLOC, significant part of that is documentation, supporting libraries and JavaScript samples (there seems to be only 40% of Java in the OpenIDM code-base). Therefore it is difficult to compare with other projects. But our best guess is that the real code-base of OpenIDM core is small, approx. 100 KLOC.
Changes in last 6 months:OpenIDM activity was moderate. There was one product release. This release introduced minimalistic GUI and some new and improved features. ForgeRock adjusted its business model in recent months which also applies to OpenIDM and may impact some OpenIDM deployments.
When to use OpenIDM: For IDM deployments that are unlike any other. Deployments that need simplicity or extreme flexibility. For deployment teams that are strong in software development and scripting.
When NOT to use OpenIDM: Projects on tight budget, projects that need to prove strict ROI or projects that otherwise needs to be cost-efficient. When there is no software development skill in the deployment team.
Our conclusion: OpenIDM is the solution for the extremes. But its efficiency for the normal case is yet to be proven. OpenIDM can handle situations that probably no other IDM solution can. But the common-case deployment with OpenIDM might turn out to be quite costly. Especially if "advanced" features are required such as RBAC or organizational structure support. Even if OpenIDM is chosen for a project the deployment team needs to be aware that what they are up to is not just a deployment project but partially also a software development project. OpenIDM may be well suitable for embedding into a larger IDM solutions. As it has very limited user interface its usability as a stand-alone system is currently severely constrained.
Full disclosure: nLight has taken part in OpenIDM development in its early stages but no longer participates in the development of OpenIDMv2. See "About nLight" below.
Side by Side
This section tries to compare Apache Syncope, midPoint and OpenIDM side by side. For a start Ohloh has nice page comparing midPoint, OpenIDM and Syncope which is continually updated. This section tries to interpret that data and also add its own observations. We will not consider OpenIAM for reasons stated above.
All three systems seems to heavily inspired by Sun IDM. Syncope take over most of that legacy reusing Sun IDM architecture and approach almost entirely. MidPoint is obviously inspired by Sun IDM but it tries to improve Sun IDM drawbacks. OpenIDM is influenced by Sun IDM only slightly (terminology, some principles) but otherwise it follows its own path. Even though all three teams started from similar ideas and experiences their approach to product development is vastly different.
Syncope and MidPoint are somehow similar in a way that they are more-or-less complete products. OpenIDM is completely different. It is not a product but rather a framework. Most of the features that Syncope and midPoint provide out-of-the-box needs to be developed in OpenIDM. However this approach makes OpenIDM the most flexible of all three products.
OpenIDM is the youngest product. The development started on a green field in mid-2011 when ForgeRock dropped OpenIDMv1. MidPoint and Syncope are of approximately the same age dating back to early 2010 (midPoint development started as OpenIDMv1). This one-year difference is clearly reflected on overall product quality.
MidPoint has the cleanest architecture and component structure. OpenIDM has good separation of components but their dependencies and structure is somehow lost in the OSGi world. Syncope has almost no internal component structure. MidPoint and Syncope are technologically similar using older proven technologies (Spring, Wicket, web application form factor). OpenIDM plunges head-first to completely new technological stack (OSGi, JSON, heavy use of JavaScript, standalone form factor).
Syncope has the most complete GUI. MidPoint is somewhere in the middle and OpenIDM has almost no GUI at all.
All three products use forks of Sun Identity Connector Framework to support provisioning connectors. While OpenIDM and midPoint cooperate on OpenICF with other companies, Syncope has its own ConnId framework but there is possibility that the two ICF fork projects get merged soon. All three products also use Activiti workflow engine (in various stages and depths of integration).
MidPoint has the smallest development team but the team is the most efficient one. MidPoint has the largest core code-base (almost twice as much as the other products) and the largest commit rate. OpenIDM and Syncope are well behind midPoint and are similar in speed of progress and core code-base size. Yet OpenIDM has much more developers. (Note: we account only for code-base of the product core, not the supporting libraries)
OpenIDM has good documentation. MidPoint has an average documentation that needs some improvement. Documentation of Syncope is very minimal and insufficient.
Syncope is obviously good for simple deployments that are similar to those of Sun IDM. It looks like Syncope is aiming at conceptual compatibility with Sun IDM deployments. This may make migrations from Sun IDM relatively easy. MidPoint is somewhere in the middle. It is still quite similar to Sun IDM and migrations may still be reasonable. MidPoint is good for a common-case scenarios. OpenIDM is a way out. It is not even conceptually compatible with Sun IDM (although some compatibility may be obviously developed given sufficient resources). OpenIDM can handle very unique deployments that no other IDM system could handle. But the flexibility comes with a price of huge deployment and maintenance effort.
Conclusion
All the open source provisioning systems are still in relatively early development stages. However all of them seems to be useful and the deployer can choose the right open-source solution for almost any IDM deployment.
Apache Syncope and midPoint are likely to be the most practical solutions for a common enterprise environment. They are also roughly equivalent when it comes to visible product features. Syncope has a better user interface while midPoint has more features under the hood. OpenIDM is a good choice for environments that require extreme flexibility and are willing to pay for it.
Overall the three closely evaluated products are open, working and reasonably complete provisioning systems. Their completeness and features considerably exceed usual industry standards considering the young age of these projects. Quality, usability and price/performance ratio of the products is much higher than usual. We are not afraid to say that in some aspects these projects exceed even the best commercial IDM offerings. It seems that open source software development concept is more than a viable alternative for IDM software. Assuming that the development teams will keep up their effort all three products are more than worth the investment of time, energy and money.
About nLight
nLight is a small consulting company focused on identity management and software architecture. nLight is a an IDM specialist from its very inception. nLight employees participated in many successful IDM deployments, some of them dating back to 1990s. nLight provided consultations and IDM trainings throughout the Europe, mostly specialized on Sun IDM deployments as we have considered that to be the only usable IDM product on the market. After the Sun IDM product was demolished and after bad experience with both Oracle and Novell products we were persuaded that the open source is the only approach that can work. Therefore nLight have been cooperating with ForgeRock on OpenIDMv1 development since almost the very beginning of OpenIDM project. When the direction of OpenIDM rapidly changed in mid-2011 the relevant part of OpenIDMv1 code was donated to a new company, Evolveum. Evolveum is now leading the development of midPoint IDM system based on the original OpenIDMv1 principles as designed by nLight engineers.