Heisenberg

Release 3.4 is a sixteenth midPoint release code-named Heisenberg. The 3.4 release brings identity governance features and significant user interface improvements. MidPoint 3.4 is one of the major milestones in midPoint project history.

Release date: 24th June 2016

Werner Heisenberg

Werner Heisenberg (1901-1976) was German theoretical physicist and one of the pioneers of quantum mechanics. He is best known for the formulation of the uncertainty principle. He also made important contributions to hydrodynamics, nuclear physics, ferromagnetism and several other fields of physics. In 1932 Werner Heisenberg was awarded the Nobel Prize in Physics.

Heisenberg's uncertainty principle asserts that there is an inherent limit to the precision with which certain physical properties of a particle can be known. Similarly to Heisenberg's principle midPoint 3.4 accepts that there is some degree of uncertainty when it comes to processing of the identity data. It may not be practically possible to always base the decisions on authoritative data. Practical identity management system needs to accept that the identity data are always in a state of flux. New mechanisms are needed to efficiently handle and process such ever changing data and midPoint 3.4 brings such mechanisms.

MidPoint 3.4 introduces the first in the series of governance and compliance mechanisms: access certification. This makes midPoint the first open source IDM system that entered the field of identity governance. Access certification campaigns can now be defined, executed and automatically remediated. MidPoint 3.4 also brings significantly improved and streamlined user interface. Similarly to the work of Werner Heisenberg that advanced the field of quantum mechanics, midPoint 3.4 has a good chance to cause a "quantum leap" in the field of identity management.

Credits

Majority of the work on the Heisenberg release was done by the Evolveum team. However, this release would not be possible without the help of our partners, customers, contributors, friends and families. We would like to express a great gratitude to all the people that contributed to the midPoint project.

Special thanks: WWK Versicherungen

MidPoint version 3.4 is named after Werner Heisenberg, German theoretical physicist who studied and worked in Munich. By doing so we would like to thank WWK Versicherungen for their ideas, support and contributions to the midPoint project. WWK Versicherungen and their team helped to improve several important parts of midPoint and we would like to express out most sincere thanks for doing this.

We would also like to thank:

Biznet Bilisim for their continuous support to midPoint project and their suggestions and ideas.

AMI Praha for their ideas and numerous contributions to the midPoint project, especially their work on localization and translations.

Symas Corporation for their ideas, suggestions and inspirations, especially in the area of OpenLDAP integration and the use of RFC3207.

Union poisťovňa for their suggestions and contributions to the midPoint project.

vnet-services for their support and constibutions to the midPoint project.

We would also like to thank individually Michael Gruber, Martin Lízner, Petr Gašparík, Roman Pudil, Shawn McKinney, Tomas Corej, Florin Stingaciu, Felix Chelu and all the midPoint contributors and community members. MidPoint would not be such a great project without you. Thank you all!

Emphasized properties that will be always displayed (even if they are empty)

Support for lockoutStatus activation mapping

Pre configured databases of locales and timezones

Full support for Java 8 environment (both build and runtime)

Diagnostics improvements (connector statistics, logging improvements)

Improved documentation

XPath2 scripting is deprecated and it is not supported in Java8 environment.

Quality

Release 3.4 (Heisenberg) is intended for full production use in enterprise environments. All features are stable and well tested.

Limitations

MidPoint 3.4 comes with a bundled LDAP-based eDirectory connector. This connector is stable, however it is not included in the normal midPoint support. Support for this connector has to be purchased separately.

Platforms

MidPoint is known to work well in the following deployment environment. The following list is list of tested platforms, i.e. platforms that midPoint team or reliable partners personally tested this release. The version numbers in parentheses are the actual version numbers used for the tests. However it is very likely that midPoint will also work in similar environments. Also note that this list is not closed. MidPoint can be supported in almost any reasonably recent platform (please contact Evolveum for more details).

Web Containers

Databases

H2 (embedded, only recommended for demo deployments)

PostgreSQL (8.4.14, 9.1, 9.2, 9.3, 9.4, 9.4.5, 9.5, 9.5.1)

MySQL (5.6.26, 5.7) Supported MySQL version is 5.6.10 and above (with MySQL JDBC ConnectorJ 5.1.23 and above). MySQL in previous versions didn't support dates/timestamps with more accurate than second fraction precision.

Oracle 11g (11.2.0.2.0)

Microsoft SQL Server (2008, 2008 R2, 2012, 2014)

Unsupported Platforms

Following list contains platforms that midPoint is known not to work due to various issues. As these platforms are obsolete and/or marginal we have no plans to support midPoint for these platforms.

Upgrade

Upgrade from midPoint 2.x

Upgrade from version 2.x is possible but it is not publicly supported. It requires several manual steps. Evolveum provides this upgrade as part of the subscription or professional services.

Upgrade from midPoint 3.0, 3.1, 3.1.1 and 3.2

Upgrade path from MidPoint 3.0 goes through midPoint 3.1, 3.1.1 and 3.2. Upgrade to midPoint 3.1 first (refer to the midPoint 3.1 release notes). Then upgrade from midPoint 3.1 to 3.1.1, from 3.1.1 to 3.2 then to 3.3 and finally to 3.4.

Upgrade from midPoint 3.3 and 3.3.1

MidPoint 3.4 data model is essentially backwards compatible with both midPoint 3.3 and midPoint 3.3.1. However as the data model was extended in 3.4 the database schema needs to be upgraded using the usual mechanism.

MidPoint 3.4 is a release that fixes some issues of previous versions. Therefore there are some changes that are not strictly backward compatible.

Version numbers of the bundled connectors have changed (LDAP, CSVfile and DatabaseTable connectors). Therefore connector references from the resource definitions that are using the bundled connectors need to be updated.

The namespace of live sync tokes was changed from http://midpoint.evolveum.com/xml/ns/public/provisioning/liveSync-1.xsd to http://midpoint.evolveum.com/xml/ns/public/provisioning/liveSync-3. This change should be harmless in most cases. However, during the upgrade some synchronization changes may go missing. This should be easy to fix by synchronizing the changes manually or by executing a reconciliation process. A completely safe migration procedure is to stop the live sync processes before upgrade, change the live synchronization token namespace in process extension (XML), upgrade midPoint and then re-start the processes again.

Workflow configuration variables processCheckInterval and allowApproveOtherItems were moved from config.xml to system configuration object.

A reminder: XPath2 scripting was deprecated in midPoint 3.3 and it is not supported in Java8 environment. XPath2 support will be removed soon. Please migrate your XPath2 scripts to Groovy, Python or JavaScript.

MidPoint configuration of approvers and approval schemas is fully backward compatible and does not need any upgrade. However the structure of Activity workflows was changed in midPoint 3.4. There is no universal migration path for running pre-3.4 workflows to 3.4 workflows. For deployments that are actively using workflows we recommend letting all running workflow processes finish before upgrading to midPoint 3.4. After finishing, manual deletion of those workflow processes is strongly recommended. For deployments that require migration of running workflow processes we recommend using midPoint subscription and ask for a migration path for that specific deployment.

The midPoint database schema was changed in midPoint 3.4 release. The migration SQL scripts are provided at the usual place. These scripts will update the database schema and they will also migrate existing data if that is possible to do on the SQL level. However there are some properties where the SQL-based migration is not possible. The migration/reindex task to handle complete data migration was not included in the midPoint 3.4 release by mistake. However, the midPoint 3.4 is robust enough to still work with data that are not fully migrated. Therefore for many deployments the data migration is usually not an immediate concern and it can be postponed to the planned 3.4.1 release which will include convenient migration/reindex task. If the data are not fully migrated the only known limitation is the search by displayName, identifier, ownerRef and riskLevel properties of roles, orgs and services. This search will not work properly (this affects only searches of identifier and displayName in org objects, other properties were not searchable in midPoint 3.3.1 and earlier, therefore that should no impact existing deployments upgrading to 3.4). In case that full data migration is required even in midPoint 3.4 there is a work round to force data migration by exporting and re-importing all roles, orgs and services.

Changes in initial objects since 3.3 and 3.3.1

MidPoint has a built-in set of "initial objects" that it will automatically create in the database if they are not present. This includes vital objects for the system to be configured (e.g. role superuser and user administrator). These objects may change in some midPoint releases. But to be conservative and to avoid configuration overwrite midPoint does not overwrite existing objects when they are already in the database. This may result in upgrade problems if the existing object contains configuration that is no longer supported in a new version. Therefore the following list contains a summary of changes to the initial objects in this midPoint release. The complete new set of initial objects is in the config/initial-objects directory in both the source and binary distributions. Although any problems caused by the change in initial objects is unlikely to occur, the implementors are advised to review the following list and assess the impact on case-by-case basis:

020-system-configuration.xml: changed userDashboardLinks colors

040-role-enduser.xml: updated authorizations

041-role-approver.xml: new file

042-role-reviewer.xml: new file

090-report-audit.xml: minor fixes

110-report-user-list.xml: minor fixes

120-security-policy.xml: new file

130-report-certification-definitions.xml: new file

140-report-certification-campaigns.xml: new file

150-report-certification-cases.xml: new file

160-report-certification-decisions.xml: new file

200-lookup-languages.xml: new file

210-lookup-locales.xml: new file

Behavior changes since 3.3 and 3.3.1

Object template and assignment focus mappings with normal strength were fixed. Due to a bug in the code in previous midPoint versions these mappings behaved in a way which was very similar to strong mappings. In midPoint 3.4 these mappings behave as they should. However, this may break previous configurations that relied on the wrong behavior, especially when it comes to multi-value items such as assignments. The solution would be to change strength of these mappings to strong.

There were several changes to the behavior of inbound mappings, mostly focused on unifying the behavior and making inbound mappings more predictable. Firstly, inbound mappings now can target also containers and references. Secondly, inbound mappings are now made to behave in non-tolerant manner. I.e. the inbound mapping will remove any values that are not explicitly given by the mapping. This behavior can be changed by setting the tolerant flag of the mapping (not the attribute) to true. This is currently an experimental feature. Enable it if you have mappings that behave in relativistic way (i.e. correctly react to changes), and you wish that they do not remove values given by other means (e.g. by direct GUI edit). However, currently it is strongly advised to avoid that situation - i.e. it is not advised to have properties that have inbound mappings and which can also be modified by other means. In such cases it is better to create a new property that will be set exclusively by the means of inbound mapping and then use object template to derive the final target value.

Public interface changes since 3.3 and 3.3.1

MidPoint authentication process was re-implemented and the underlying libraries (Spring Security) were upgraded. This may bring slight changes in result and error codes for authentication and authorization failures. This may affect all remote interfaces.

Important internal changes since 3.3 and 3.3.1

These changes should not influence anyone using the midPoint. These changes should also not influence the XML-based customizations or scripting expressions that rely just on the provided library classes. These changes will influence midPoint forks and deployments that are heavily customized using the Java components.

The audit Java API was changed to allow passing target values for which we do not have full object (just OID).

Known Issues

When account references resource which references connector that has been upgraded, linkref is removed from user
MID-3251
-
When account references resource which references connector that has been upgraded, linkref is removed from userClosed

Error when object has extra extension attributes in repo
MID-3249
-
Error when object has extra extension attributes in repoResolved