Skip to end of metadata
Go to start of metadata

MidPoint Project

What is midPoint?

Midpoint is a comprehensive identity management and identity governance system. It basically an complex integration tool that can replicate and transform user records between numerous user databases, management of the records, reporting, auditing and so on. It allows very complex transformation and replication rules including support for advanced RBAC and scripting. Its internal mechanisms are based on state-of-the art concepts that are still not yet widely used in the field of Identity Management.

Please see Enterprise Identity Management for a generic introduction to the Identity Management (IDM) concepts. Please see the Unique Features for a short description of features that make midPoint unique.

How is midPoint related to Sun Identity Manager (Oracle Waveset)?

The core of team that is developing midPoint is composed of identity management and software engineers. The engineers has a long experience and deep knowledge of the IDM field. Sun IDM (a.k.a. Oracle Waveset) was a prominent product in this field. Therefore it is understandable that it has influenced the thinking that lead to the development of midPoint. Engineers that know Sun IDM will find many midPoint concepts quite familiar.

However, midPoint is a green-field project. The code of midPoint is not based on any code of the core Sun IDM (except for connectors, see below). It was not even possible because the code of Sun IDM was not released under an open-source license.

How is midPoint related to OpenIDM?

MidPoint is based on parts of the code developed by our engineers during their work on OpenIDM version 1. However ForgeRock decided to dramatically change the direction of OpenIDM development and therefore midPoint is developed as an independent project since April 2011. MidPoint has evolved significantly from these early times and only a very little original code remains. The most important features that make midPoint unique were added to midPoint after the split from OpenIDM when developers were free to pursue their own path of product development.

Currently midPoint and OpenIDMv2 are two independent projects that do not share any significant part of the codebase except the OpenICF connector layer (see below).

Please see the midPoint History page for a complete description of midPoint development history.

How is midPoint related to ConnId, OpenICF and Sun Identity Connector Framework?

ConnId is an open-source project that aims to develop a reusable identity connector framework and a basic set of connectors. It has started as an Identity Connector Framework project by Sun Microsystems to be used as part of Sun IDM. However, the open-source project was efficiently stopped after the acquisition of Sun Microsystems by Oracle. The ConnId framework is open source continuation of that project.

ConnId is currently developed by several independent parties and Evolveum is one of the major contributors. ConnId is currently used as the primary connector framework for midPoint.

OpenICF is a similar framework based on Sun Identity Connector Framework. It is currently maintained by ForgeRock. MidPoint has been using OpenICF in the past. But due to various reasons the midPoint project has completely migrated to ConnId. Evolveum is no longer contributing to OpenICF or any OpenICF connector. OpenICF and ConnId are partially compatible. Some OpenICF connectors can still be used in midPoint. However, we consider OpenICF support to be a legacy and it will most likely going to be phased out.

How does midPoint Differ from ...

How Does midPoint Differ from Sun Identity Manager (Oracle Waveset)

MidPoint is somehow influenced by the Sun Identity Manager (Sun IDM, currently Oracle Waveset) design and features and midPoint somehow follows similar approach to provisioning that was introduced by Sun IDM. Therefore engineers that are used to work with Sun IDM will find some parts of midPoint quite familiar. However, even though Sun IDM was a good product it was far from perfect. There were severe architectural issues in Sun IDM and we are well aware of them. MidPoint has a different implementation architecture and the development team tries very hard not to repeat the mistakes of Waveset and Sun IDM development teams.

The similarities are:

  • Developed mostly in Java
  • Web application form (WAR) and easy deployment
  • Integrated workflow engine
  • Most IDM concepts (Users, Accounts, Resources, Roles, ...)
  • Powerful web-based administration GUI (continually under development)

Major differences include:

  • Open source character
  • Newer and lighter infrastructure (spring, wicket, ...)
  • Cleaner internal architecture
  • Use of standard scripting tools (Groovy, JavaScript, Python) instead of proprietary XPRESS
  • Use of standard workflow language (BPMN) instead of a proprietary one
  • MidPoint is based on relative changes which avoids critical drawbacks of Sun IDM consistency model
  • While workflow has a major control over provisioning, MidPoint provisioning is not directly driven by workflow. It is rather driven by declarative statements that make it easier to handle errors, implement high-level consistency, handle provisioning dependencies, handle parallelism, etc.
  • MidPoint contains identity governance features while Sun IDM is just a provisioning engine.
  • MidPoint lives while Sun IDM (Oracle Waveset) is as good as dead now.

Disclaimer: This information is provided only as our own opinion. Although we have tried to do our best and be as objective as possible this comparison was based on incomplete data provided under very confusing circumstances and conditions. It is possible that this information is neither complete nor entirely correct. Therefore the reader is advised to do own independent research into this topic and not rely only on information provided here.

How Does midPoint Differ from OpenIDM

MidPoint and OpenIDM share a part of common past (see midPoint History). Yet these two products are currently almost entirely separate. Their architecture, principle, development model and also approach to IDM is vastly different.

The similarities are:

  • They share some ideas that were introduced in OpenIDMv1 (but the implementation is entirely different)
  • Integrated workflow engine (Activiti)
  • Support for scripting languages (JavaScript, Groovy)

Major differences include:

  • MidPoint is an open source project. OpenIDM is not entirely open (e.g. current source code is not available).
  • While midPoint is complete product that is useful out-of-the box OpenIDM is mostly just a framework. While the solution is mostly configured in midPoint it needs to be developed in OpenIDM which usually requires a significant part of scripting.
  • MidPoint is focused on efficient IDM deployment for common case. OpenIDM seems to be more suitable for extraordinary deployments that require extreme flexibility.
  • MidPoint is web application (WAR) while OpenIDM is a stand-alone engine based on OSGi.
  • MidPoint is based on relative changes while OpenIDM consistency model seems to rely on more traditional optimistic locking techniques.
  • MidPoint has rich user interface. OpenIDM has only a very minimal GUI.
  • MidPoint has an advanced RBAC mechanism. OpenIDM has only a very limited support RBAC for provisioning.
  • MidPoint contains identity governance features while OpenIDM is only a simple provisioning framework with no governance features at all.
  • MidPoint has an out-of-the box support for organizational structure. OpenIDM does not have such concept.

See also in depth comparison of open source provisioning products.

Disclaimer: This information is provided only as our own opinion. Although we have tried to do our best and be as objective as possible this comparison was based on incomplete data provided under very confusing circumstances and conditions. It is possible that this information is neither complete nor entirely correct. Therefore the reader is advised to do own independent research into this topic and not rely only on information provided here.

How Does midPoint Differ from Apache Syncope

Apache syncope is a perspective project of an open source provisioning engine. Syncope is also inspired by Sun IDM, but the inspiration goes much deeper than in midPoint.

The similarities are:

  • Open source character
  • Developed mostly in Java
  • Web application form (WAR) and simple deployment
  • They both use ConnId connector framework
  • They share some ideas inspired by Sun IDM
  • Integrated workflow engine (Activiti)

Major differences include:

  • MidPoint has more advanced features under the hood. Syncope seems to be simpler in the engine logic.
  • MidPoint has a rich administration GUI. Syncope administration GUI is slightly simpler.
  • MidPoint tries to be innovative in many aspects. Syncope sticks with quite proven architecture similar to Sun IDM.
  • MidPoint is based on relative changes while Syncope consistency model seems to rely database transactions and similar mechanisms.

See also in depth comparison of open source provisioning products.

Disclaimer: This information is provided only as our own opinion. Although we have tried to do our best and be as objective as possible and the Syncope team was very helpful it is not possible to understand every aspect of the technology. It is possible that this information is neither complete nor entirely correct. Therefore the reader is advised to do own independent research into this topic and not rely only on information provided here.

How Does midPoint Differ from Oracle Identity Manager

Oracle Identity Manager (OIM) is a provisioning tool based on relational database principles. It was developed by Thor Technologies (as Thor Xellerate) and later acquired by Oracle. Although we might have a detailed technical information about OIM we are not sure whether we are allowed to publish it. Therefore we provide only the basic facts that can be learned from the publicly available documents:

The similarities are:

  • Almost none. The two products seems to be fundamentally different in most aspects.
  • Recent versions OIM seems to use the clone of Sun ICF connector framework which is similar to midPoint (see below)

Major differences include:

  • Open source vs closed source character that seems to go very deep into the project culture (also see the ICF remark below).
  • OIM deployment and installation seems to be considerably heavyweight and costly. MidPoint deployment and configuration model is very modern and lightweight.
  • We believe that midPoint provides significantly better deployment efficiency than OIM
  • OIM seems to be heavily based on relational database concepts while midPoint has a flexible data access abstraction.
  • OIM traditionally relied on heavyweight data replication and reconiciliation. MidPoint architecture is closer to virtual data representations.
  • The approach, tooling and business approach of midPoint seems to better suit the continuous incremental IDM programs as opposed to a complex monolithic IDM projects.
  • MidPoint contains integral identity governance features while OIM is just a provisioning engine. Governance is implemented as a separate Oracle product that is only partially integrated with OIM and needs to be purchased, deployed and configured separately.

Recent versions of OIM seems to be using a fork of Identity Connector Framework (ICF) which was originally developed by Sun Microsystems. However the version of ICF framework which is used by OIM is no longer developed in open-source fashion. Therefore it is possible that it still contains severe framework and connector issues that were discovered and are currently being addressed in the open source version of the framework.

Disclaimer: This information is provided only as our own opinion. Although we have tried to do our best and be as objective as possible this comparison was based on incomplete data provided under very confusing circumstances and conditions. It is possible that this information is neither complete nor entirely correct. Therefore the reader is advised to do own independent research into this topic and not rely only on information provided here.

How Does midPoint Differ from NetIQ Identity Manager (Novell Identity Manager)

NetIQ Identity Manager is a directory-based provisioning engine developed by Novell. Similarly to the previous question we are not sure how much information we are allowed to publish. Therefore we provide only the basic facts that can be learned from the publicly available documents:

The similarities are:

  • Some ideas behind the change propagation approach
  • almost nothing else

Major differences include:

  • Open source character
  • MidPoint deployment and configuration model seems to be much more lightweight
  • NetIQ seems to be based on adapted meta-directory concept. MidPoint is a pure provisioning engine.
  • The approach, tooling and business approach of midPoint seems to better suit the continuous incremental IDM programs as opposed to a complex monolithic IDM projects.
  • MidPoint contains integral identity governance features while NetIQ is just a provisioning engine.

Disclaimer: This information is provided only as our own opinion. Although we have tried to do our best and be as objective as possible this comparison was based on incomplete data provided under very confusing circumstances and conditions. It is possible that this information is neither complete nor entirely correct. Therefore the reader is advised to do own independent research into this topic and not rely only on information provided here.

Architecture and Features

What are the basic technological foundations of midPoint?

MidPoint is implemented as a Java application. Currently it is distributed as a traditional Java web application (WAR) but the architecture allows support for more application formats in the future (e.g. OSGi). The basic application framework is based on Spring. MidPoint is using the usual set of open-source infrastructure libraries (e.g. SLF4J, logback, Apache commons, etc.) MidPoint user interface is based on Apache Wicket framework.

What do I need to run midPoint?

MidPoint is a Java application that is currently distributed as Java web application (WAR). Therefore it needs a Java web container to run. Most of the midPoint testing is executed in Apache Tomcat web container and that is also the recommended container to run midPoint. In addition to this the range of supported containers is growing with each midPoint release. However there is no strict list of supported platforms, containers and versions. The team is committed to provide support for running midPoint on any widespread and reasonably recent web container if the user (or partner) is willing to provide assistance with the testing.

What user interface midPoint provides?

MidPoint provides a graphical administration and user interface (GUI) in a form of rich web application (AJAX). It is a integral part of midPoint releases and it is a primary midPoint administration tool. Although the GUI is part of midPoint the GUI layer is clearly separated from the back-end layer using well-defined interfaces. Therefore it is possible to adapt or even replace the GUI if needed. Complete midPoint source code is open-source therefore the user is not limited to configuration and can freely modify and adapt the code.

What services midPoint provides?

MidPoint provides a web service for the vital provisioning functions. This service can be used to modify and control vast majority of midPoint functions. The web service is currently provided in a SOAP/WSDL form with full schema support. The REST versions of the service are also available.

What connectors and resource types midPoint supports?

MidPoint is using ConnId connector framework. Therefore it supports any connector that is compliant with the ConnId framework. Currently the connectors support the usual IDM cases such as Active Directory, LDAP, flat files, relational databases, etc. Please see the Identity Connectors page for a list of currently available connectors.

Can midPoint synchronize passwords from Active Directory or LDAP?

The backward password sync channel is quite difficult to do. Both AD and LDAP store passwords hashed. Therefore it is not directly possible to get the clear value by just reading the userPassword attribute. And the hashes are not compatible, so we need a clear value to transform one to the other.

The only practical way that we have found is to use agents. That means a piece of code that will get between setting the password and hashing it on AD/LDAP side and sends the cleartext password to midpoint. This is clearly not the best idea from a security point of view. But it you require password sync then we do not know about any other way.

Also, the agents that are ready to use with midpoint do not exist yet. We are currently experimenting with AD. But this has quite a low priority and we cannot predict any outcome now. The LDAP agent will be specific for each and every LDAP server. We have done some prototyping work with OpenDJ and the approach seems to be feasible. But this is also a very low-priority task.

The approach that we usually recommend it to avoid this kind of password synchronization altogether. It has considerable security, consistency and operational issues (e.g. how to handle password notifications that arrive before the account creation event is synchronized? What do to with passwords that comply with source password policy but do not comply with target password policy? etc ...)

The recommended approach is to use midPoint as a point of central password management. Users should change and manage their passwords in midPoint. The password can then be easily replicated to any other system (resource). MidPoint can also enforce consistent password policies, make sure that the passwords are same (or different) on several resources (in the future) and so on.

Does midPoint supports Single Sign-On (SSO)?

Yes and no. MidPoint is user provisioning system, not access management system. Therefore midPoint is neither authentication server not a SSO server. There are numerous possibilities how to implement these services by using an existing software, ranging from simple LDAP server to a sophisticated flexible access management suites. MidPoint has no ambition to reinvent the wheel of access management therefore it does not contain access management services. A comprehensive explanation of IDM solution components can be found on Enterprise Identity Management page.

However midPoint can integrate with access management software on two levels:

  • MidPoint can manage the user database of access management system by provisioning to it. This is very common integration scenario.
  • MidPoint can be a SSO client under some circumstances. For example it can be SSO client for Active Directory system by correctly configuring midPoint spring security settings (may currently require some customization). Alternatively midPoint is just a web application therefore it can be integrated to a web-SSO system as an ordinary web application.

Does midPoint have end-user interface (GUI) similar to what Sun IDM (Waveset) used to have?

We do not have and we do not plan a special-purpose simplified end-user GUI. There are several reasons:

Firstly, the end-user interface usually has a lot forms and styles. It is customized for almost every non-trivial deployment. E.g. some customers want a standard portlet others want proprietary portlet, yet others want to integrate it in their current core information system, etc. We have found out that it may in fact be easier to develop the end-user GUI for each deployment than to create and maintain a customizable code.

MidPoint is open-source project so any deployer can take the current GUI, strip it down to the very minimum, customize it or even write its own code. MidPoint follows a strict architectural approach of separating display logic and business logic. The GUI is using IDM Model Interface to execute all the IDM-related "business" and integration logic. Therefore none of this needs to be re-implemented in a custom GUI. This interface is also available as a web service which is suitable for supporting a (remote) portlet or a similar GUI form factor.

Secondly, the minimal end-user GUI has a very limited features. E.g. it is usually not possible to fully interact in workflows or delegated administration using a minimal end-user GUI. Significant percentage of users usually require at least some portions of the administration GUI (delegated administrators, approvers, auditors, etc.) It means that a real value of a separate simple end-user GUI is quite limited.

The long-term plan for midPoint GUI is to use existing administration GUI for both administration and end-user interactions. We are working on a fine-grained authorization subsystem that will allow limiting users to a specific parts of the midPoint functionality. This is also planned to work with a delegated administration and workflows. The current plan is to have basic framework in place in version 2.2 and to have a complete subsystem in 3.0 or 3.1 (all the plans still subject to change).

I need midPoint to support feature X. What should I do?

Please see I Need New Feature

Setup and Customization

Why does midPoint execute outbound mappings during import from resource?

Import from resource imports the accounts from a resource and creates midPoint users. Inbound mappings are usually used to populate the users with values. However if there are also outbound mappings from the user to other (or even the same) accounts these mappings will be executed as well.

MidPoint tries to execute all the mappings and all the synchronization logic anytime it can. Immediately. This may be quite a different philosophy as compared to other IDM systems but there is a strong reasoning to do so:

  1. Executing all the applicable mappings as soon as possible gives almost-realtime character to the synchronization. Propagating changes as soon as they are detected lowers risk of consistency problems.
  2. All the synchronization logic needs to be executed sooner or later otherwise consistency is broken. Many other IDM systems postpone the execution of parts of synchronization logic to a later time, to a different task, etc. This may be more efficient from a performance point of view and it forms a cleaner event-oriented architecture. But it has a severe practical drawback. Cause-and-effect trail is practically lost. If there is a problem in a synchronization logic that was postponed it is almost impossible to figure out the original cause. Such systems are very difficult to maintain. MidPoint tries to avoid this by executing everything as soon as it can. Therefore the configuration problems are evident when all the data are fresh and still available. Executing all the mappings together maintains a cause-and-effect trail. This significantly improves diagnostics and troubleshooting of the configuration and customizations.

This is a generic mechanism that applies not only to import but to all flavours of synchronization and provisioning in midPoint.

This "execute everything immediately" approach is ideal for a sustained operation of the system. However, it may be slightly inconvenient during initial imports and migration. Therefore there are few tips how to work around it:

  • Import the data first, create outbound mappings after the data are imported
  • Application of mappings can be constrained to a specific channel. Import has its own channel therefore some mappings may be constrained only to be executed during import.
  • Spend more time setting up the outbound mappings correctly. Use import not just to get the data inside midPoint but also to test that the outbound mappings work well. This requires more time during initial import but the time will pay off after the deployment.

Installation, Deployment and Operation

I found in log warning "midpoint.home is not set"

This warning is displayed during the starting of midPoint. It can be ignored unless you want to use a custom directory for your embedded repository or custom connectors. Please refer to the Directory for Custom Components (midpoint.home) section.

After login, all I see is error "Currently we are unable to process your request. Kindly try again later."

This happens if there is problem with JCE (Java Cryptography Extension) libraries.
Have you installed JCE libraries?
Have you just recently upgraded your Java? This might replace your JCE libraries.

See "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6" chapter in Installation Guide

Synchronization or provisioning throws exception: "Illegal key size"

This happens if there is problem with JCE (Java Cryptography Extension) libraries.

Have you installed JCE libraries?
Have you just recently upgraded your Java? This might replace your JCE libraries.

See "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6" chapter in Installation Guide

Missing sn attribute on LDAP

The following error may be encountered while using a LDAP connector:

The immediate cause of that error is a missing sn attribute. The sn attribute is mandatory in the usual LDAP inetOrgPerson objectclass. Therefore attempt to create and account without this attribute fails. The missing sn attribute is most likely caused by no value in user's familyName property which is usually the source of the sn attribute mapping.

The simples solution is to either make sure that the familyName property is always filled. Alternatively a more sophisticated mapping may be created for the sn attribute, e.g. taking value from the fullName property if the familyName is not filled in.

Connectors are not detected upon midPoint start

If you start midPoint and your connectors are not detected and therefore Connector objects not created in repository, check your "config.xml" file located in "midPoint.home" directory. The following parameters should be set:

config.xml

The "scanClasspath=true" parameter will detect the connectors bundled with midPoint, while the "scanDirectory" parameter defines the directory where custom connectors can be detected.

What are midPoint Availability Requirements?

It depends mostly on your requirements. How long you can live without ability to change passwords and assign/unassign roles? That's perhaps the only midPoint function that is sensitive to availability.

All other midPoint functions are resilient and they can recover even from long outages (days) without any loss in data. E.g. it is not an important difference if synchronization or reconciliation tasks will process the data a second after the change or few minutes later. MidPoint can also easily recover from changes done manually on the target systems. Therefore even if midPoint is down there is still option to disable the accounts manually (e.g. during security incident), to manually create testing accounts and so on. If midPoint is configured correctly then it will re-establish the consistency after it recovers from the failure.

Therefore the availability parameters depend on your requirements. Typical downtime requirements allow for 99.9% availability (which is approx. 8 hours per year) or even less. Practical cases suggest that even if the system is down more than a hour each month then there is no real impact on any essential services.

Integration

I want to invoke midPoint operations from my application.

There are several Interfaces that you can use. Namely:

All the three interfaces provide services that are roughly equivalent. Approximately 95% of all midPoint features are available by using these interfaces. We are using the local Java API ourselves (as given by midPoint architecture), so almost all features that you can see in midPoint GUI is available in all of these interfaces.

I want to use the SOAP-based web service interface. Where do I start?

First, you should understand midPoint data model. All the interfaces are based on the paradigm of modifying data model objects. This page is a good start: Basic Data Model

The formal interface definition can be found here: IDM Model Web Service Interface

The data model is governed by the XSD schema, which is also referenced in the interface definition (WSDL). See the individual XSD files for details, they are reasonably well documented inline. The XSD files and interface definitions are also conveniently bundled in midPoint binary distribution. So you should already have them when you downloaded midPoint. Additionaly, you can refer to the generated data model documentation: SchemaDoc

There is a wiki page that provides wire-level examples of the interface usage. This is interesting especially for non-Java and non-schema-aware clients (most scripting languages): IDM Model Web Service Interface Examples

For Java applications we have created a complete library that contains already generated Java classes for all the data model entities. This can be conveniently used as a JAX-WS client: Model Web Service Client

To get some idea about interface usage see Model Web Service Client Sample. This sample code contains several common operations over midPoint objects.

Even more examples can be found by examining the test code. There is one test that is especially designed to test the web service: https://github.com/Evolveum/midpoint/tree/master/testing/wstest

Support

Where can I get support?

There are two broad categories of support:

  • Community support: this is free best effort service. Ask your question on midPoint Mailing Lists. But there are no guarantees.
  • MidPoint subscription: this is commercial support program provided by Evolveum. The details about the subscription programs are also available at support page of Evolveum website.

I have found a bug in midPoint. I want it fixed.

See I Have Found a Bug.

Why is my bug not fixed yet? I have reported it weeks ago!

See Why is my bug not fixed yet?

How do I get midPoint subscription?

You can get midPoint subscription from Evolveum. It is simple: just contact us. The details about the subscription programs are also available at support page of Evolveum website.

External links

 

  • No labels