release-notes.adoc

layout	release-version	visibility
release	4.10	hidden

MidPoint 4.10

Release 4.10 is a sixtieth midPoint release, code-named Verne. The 4.10 release brings improvements in role engineering, certification, approvals, stability and miscellaneous improvements.

{% include release-data.html %} {% capture dedicationContent %}

Jules Gabriel Verne (1828-1905) was a French novelist, poet, and playwright. His best-selling novels, always well-researched according to the scientific knowledge then available, taking into account the technological advances of the time. Verne, considered to be one of the fathers of science-fiction genre, inspired several generations of readers.

Similarly to Verne's novels, midPoint 4.9 brings several technological advancements, bringing them from the drawing board to real life. Shadow caching and value metadata were prototyped a long time ago, they became production-quality reality in midPoint 4.9. Improvements in role mining and brand-new outlier detection functionality are reaching up to the boundaries of science fiction. The new access certification look and feel is reminiscent of the colorful worlds that Verne has described. Other features and improvements of this release make midPoint more complete, easier to use and much more sophisticated. Overall, midPoint 4.9 is a major step from the past into the future.

{% endcapture %} {% include release-dedication.html content=dedicationContent %}

Changes With Respect To Version 4.9

New Features and Major Improvements

• bug:MID-10147[] Added support for new capability lastLoginTimestamp.

Other Improvements

• Update GUI views after changing of the archetype, that is used in the view. See bug:MID-9776[].

• Adding support for PKCE (Proof Key for Code Exchange) as additional security for OIDC authentication module. See bug:MID-10155[].

• Adding new configuration attribute for OIDC authentication module, that is used for ID Token signing algorithm. See Oidc Module.

Releases Of Other Components

• New version (1.5.2.0) of DatabaseTable Connector was released and bundled with midPoint. The connector suggest all names of columns for configuration properties related with name of column.

• New version (2.8) of CSV Connector was released and bundled with midPoint. The connector suggest all names of columns for configuration properties related with name of column.

  • Fixed NPE with multivalue attributes when delimiter is not defined. (bug:MID-8609[]).

  • Fix UTF-8 BOM character in csv file during of discovery functions. (bug:MID-9497[] and bug:MID-9498[]).

• New version (3.8) of AD/LDAP Connector was released and bundled with midPoint. The connector suggest all names of columns for configuration properties related with name of column.

  • Native association support.

  • Possibility to choose attributes that should not be returned by default.

  • Possibility to choose to encode string values in case of the presence of non standard ASCII characters.

  • Workaround for open-ldap mandatory member attribute.

  • Possibility to specify used auxiliary object classes in connector configuration.

  • Allow to send the LDAP_DIRSYNC_OBJECT_SECURITY flag in Active Directory sync request control.

{% include release-quality.html %}

Limitations

Following list provides summary of limitation of this midPoint release.

• Functionality that is marked as Experimental Functionality is not supported for general use (yet). Such features are not covered by midPoint support. They are supported only for those subscribers that funded the development of this feature by the means of subscriptions and sponsoring or for those that explicitly negotiated such support in their support contracts.

• MidPoint comes with bundled LDAP Connector. Support for LDAP connector is included in standard midPoint support service, but there are limitations. This "bundled" support only includes operations of LDAP connector that 100% compliant with LDAP standards. Any non-standard functionality is explicitly excluded from the bundled support. We strongly recommend to explicitly negotiate support for a specific LDAP server in your midPoint support contract. Otherwise, only standard LDAP functionality is covered by the support. See LDAP Connector page for more details.

• MidPoint comes with bundled Active Directory Connector (LDAP). Support for AD connector is included in standard midPoint support service, but there are limitations. Only some versions of Active Directory deployments are supported. Basic AD operations are supported, but advanced operations may not be supported at all. The connector does not claim to be feature-complete. See Active Directory Connector (LDAP) page for more details.

• MidPoint user interface has flexible (responsive) design, it is able to adapt to various screen sizes, including screen sizes used by some mobile devices. However, midPoint administration interface is also quite complex, and it would be very difficult to correctly support all midPoint functionality on very small screens. Therefore, midPoint often works well on larger mobile devices (tablets), but it is very likely to be problematic on small screens (mobile phones). Even though midPoint may work well on mobile devices, the support for small screens is not included in standard midPoint subscription. Partial support for small screens (e.g. only for self-service purposes) may be provided, but it has to be explicitly negotiated in a subscription contract.

• There are several add-ons and extensions for midPoint that are not explicitly distributed with midPoint. This includes xrefv:/midpoint/reference/support-4.9/interfaces/midpoint-client-java/[Java client library], various samples, scripts, connectors and other non-bundled items. Support for these non-bundled items is limited. Generally speaking, those non-bundled items are supported only for platform subscribers and those that explicitly negotiated the support in their contract.

• MidPoint contains a basic case management user interface. This part of midPoint user interface is not finished. The only supported parts of this user interface are those that are used to process requests, approvals, and manual correlation. Other parts of case management user interface are considered to be experimental, especially the parts dealing with manual provisioning cases.

This list is just an overview, it may not be complete. Please see the documentation regarding detailed limitations of individual features.

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 with this release. The version numbers in parentheses are the actual version numbers used for the tests.

It is very likely that midPoint will also work in similar environments. But only the versions specified below are supported as part of midPoint subscription and support programs - unless a different version is explicitly agreed in the contract.

Operating System

MidPoint is likely to work on any operating system that supports the Java platform. However, for production deployment, only some operating systems are supported:

• Linux (x86_64)

• Windows Server (2022)

We are positive that midPoint can be successfully installed on other operating systems, especially macOS and Microsoft Windows desktop. Such installations can be used to for evaluation, demonstration or development purposes. However, we do not support these operating systems for production environments. The tooling for production use is not maintained, such as various run control (start/stop) scripts, low-level administration and migration tools, backup and recovery support and so on. Please see [/midpoint/install/bare-installation/platform-support/] for details.

Note that production deployments in Windows environments are supported only for LTS releases.

Java

Following Java platform versions are supported:

• Java 21. This is a recommended platform.

• Java 17.

OpenJDK 21 is the recommended Java platform to run midPoint.

Support for Oracle builds of JDK is provided only for the period in which Oracle provides public support (free updates) for their builds.

MidPoint is an open source project, and as such it relies on open source components. We cannot provide support for platform that do not have public updates as we would not have access to those updates, and therefore we cannot reproduce and fix issues. Use of open source OpenJDK builds with public support is recommended instead of proprietary builds.

Databases

Since midPoint 4.4, midPoint comes with two repository implementations: native and generic. Native PostgreSQL repository implementation is strongly recommended for all production deployments.

See xrefv:/midpoint/reference/support-4.9/repository/repository-database-support/[] for more details.

Since midPoint 4.0, PostgreSQL is the recommended database for midPoint deployments. Our strategy is to officially support the latest stable version of PostgreSQL database (to the practically possible extent). PostgreSQL database is the only database with clear long-term support plan in midPoint. We make no commitments for future support of any other database engines. See xrefv:/midpoint/reference/support-4.9/repository/repository-database-support/[] page for the details. Only a direct connection from midPoint to the database engine is supported. Database and/or SQL proxies, database load balancers or any other devices (e.g. firewalls) that alter the communication are not supported.

Native Database Support

xrefv:/midpoint/reference/support-4.9/repository/native-postgresql/[Native PostgreSQL repository implementation] is developed and tuned specially for PostgreSQL database, taking advantage of native database features, providing improved performance and scalability.

This is now the primary and recommended repository for midPoint deployments. Following database engines are supported:

• PostgreSQL 16, 15, 14

PostgreSQL 16 is recommended.

Generic Database Support (deprecated)

xrefv:/midpoint/reference/support-4.9/repository/generic/[Generic repository implementation] is based on object-relational mapping abstraction (Hibernate), supporting several database engines with the same code. Following database engines are supported with this implementation:

• Oracle 21c

• Microsoft SQL Server 2019

Support for xrefv:/midpoint/reference/support-4.9/repository/generic/[generic repository implementation] together with all the database engines supported by this implementation is deprecated. It is strongly recommended to migrate to xrefv:/midpoint/reference/support-4.9/repository/native-postgresql/[native PostgreSQL repository implementation] as soon as possible. See xrefv:/midpoint/reference/support-4.9/repository/repository-database-support/[] for more details.

Supported Browsers

• Firefox

• Safari

• Chrome

• Edge

• Opera

Any recent version of the browsers is supported. That means any stable stock version of the browser released in the last two years. We formally support only stock, non-customized versions of the browsers without any extensions or other add-ons. According to the experience most extensions should work fine with midPoint. However, it is not possible to test midPoint with all of them and support all of them. Therefore, if you chose to use extensions or customize the browser in any non-standard way you are doing that on your own risk. We reserve the right not to support customized web browsers.

Important Bundled Components

Table 1. Important bundled components

Component	Version	Description
Tomcat	10.1.28	Web container
ConnId	1.6.0.0-RC1	ConnId Connector Framework
LDAP connector bundle	3.8	LDAP and Active Directory
CSV connector	2.8	Connector for CSV files
DatabaseTable connector	1.5.2.0	Connector for simple database tables

{% include release-download.html %}

Upgrade

MidPoint is a software designed with easy upgradeability in mind. We do our best to maintain strong backward compatibility of midPoint data model, configuration and system behavior. However, midPoint is also very flexible and comprehensive software system with a very rich data model. It is not humanly possible to test all the potential upgrade paths and scenarios. Also, some changes in midPoint behavior are inevitable to maintain midPoint development pace. Therefore, there may be some manual actions and configuration changes that need to be done during upgrades, mostly related to feature lifecycle.

This section provides overall overview of the changes and upgrade procedures. Although we try to our best, it is not possible to foresee all possible uses of midPoint. Therefore, the information provided in this section are for information purposes only without any guarantees of completeness. In case of any doubts about upgrade or behavior changes please use services associated with midPoint subscription programs.

Please refer to the xrefv:/midpoint/reference/support-4.9/upgrade/upgrade-guide/[] for general instructions and description of the upgrade process. The guide describes the steps applicable for upgrades of all midPoint releases. Following sections provide details regarding release 4.10.

Upgrade From MidPoint 4.8

MidPoint 4.10 data model is backwards compatible with previous midPoint version. Please follow our xrefv:/midpoint/reference/support-4.9/upgrade/upgrade-guide/[Upgrade guide] carefully.

Important

Be sure to be on the latest maintenance version for 4.8, otherwise you will not be warned about all the necessary schema changes and other possible incompatibilities.

Note that:

• There are database schema changes (see xrefv:/midpoint/reference/support-4.9/upgrade/database-schema-upgrade/[Database schema upgrade]).

• Version numbers of some bundled connectors have changed. Connector references from the resource definitions that are using the bundled connectors need to be updated.

• See also the Actions required information below.

Upgrade From Other MidPoint Versions

Upgrade from midPoint versions other than 4.8.x to midPoint 4.10 is not supported directly. Please upgrade to 4.8.5 first.

Deprecation, Feature Removal And Major Incompatible Changes Since 4.8

Note	This section is relevant to the majority of midPoint deployments. It refers to the most significant functionality removals and changes in this version.

Changes In Initial Objects Since 4.8

Note	This section is relevant to the majority of midPoint deployments.

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., the role Superuser and the user administrator). These objects may change in some midPoint releases. However, midPoint is conservative and avoids overwriting customized configuration objects. Therefore, 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.

The following list contains a description 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.

Actions required: Please review the changes and apply them appropriately to your configuration. Ninja can help with updating existing initial objects during upgrade procedure using initial-objects command. For more information see xrefv:/midpoint/reference/support-4.9/deployment/ninja/use-case/upgrade-with-ninja/#initial-objects[here].

• 040-role-enduser.xml: The End user role was updated with a hidden visibility for myCertificationItems dashboard widget.

• 042-role-enduser.xml: The Reviewer role was extended with myActiveCertificationCampaigns UI authorization for active campaigns page and with more items of the certification campaign object to be read.

• 000-system-configuration.xml: The SystemConfiguration object was extended with a new dashboard widget configuration for certification items.

• 250-object-collection-resource.xml: The All resources object collection was updated with a filter to exclude resource templates.

• 251-object-collection-resource-up.xml: The Resources up object collection was updated with a filter to exclude resource templates.

• 520-archetype-task-certification.xml: Changes for proper functioning of certification related tasks.

• 534-archetype-task-certification-campaign-open-next-stage.xml: Archetype for campaign open next stage (start campaign) related task.

• 535-archetype-task-certification-remediation.xml: Archetype for campaign remediation related task.

• A set of initial objects was updated to extend polystring type elements with translation keys configuration. The full set of changed objects you can see in the commit with some further changes in the next commits: archetype correlation case label fix, fixes in system configuration object, archetype and report objects fixes, application label fix.

• 029-archetype-application.xml: updated panels for application archetype.

• 700-archetype-event-mark.xml: updated admin gui configuration - hidden object operation policy panel.

• 800-804 marks: updated object operation policy membership.

• 030-role-superuser.xml: updated policy.

Please review source code history for detailed list of changes.

Tip	Copies of initial object files are located in config/initial-objects directory of midPoint distribution packages. These files can be used as a reference during upgrades. On-line version can be found in midPoint source code.

Schema Changes Since 4.8

Note	This section is relevant to the majority of midPoint deployments. It describes what data items were marked as deprecated, or removed altogether from the schema. You should at least scan through it - or use the ninja tool to check the deprecations for you.

Table 2. Items being deprecated

Type	Item or value	Note
AccessCertificationConfigurationType	availableResponse	Configure actions in the cert. items collection view instead.
ItemRefinedDefinitionType	emphasized	Use displayHint instead.
ResourceObjectTypeDefinitionType	association	Use association types (in schemaHandling) instead.
ResourceObjectTypeDefinitionType	protected	Use "marking" instead.
ShadowType	association	Legacy associations of this shadow. Not used anymore.
SynchronizationActionsType	unlink	Use <synchronize/> action instead.

The synchronize/membership container was added to the object operation policy object, present in xrefv:/midpoint/reference/support-4.9/concepts/mark/[object marks] (like the Protected one). It controls the handling of the membership of entitlements possessing given object mark.

Actions required:

• Inspect your configuration for deprecated items, and replace them by their suggested equivalents. Make sure you don’t use any removed items. You can use ninja tool for this.

• Be sure to apply the changes to initial objects 800-804 (object marks), as well as to your custom object marks to handle the membership in the expected way.

Behavior Changes Since 4.8

Note

This section describes changes in the behavior that existed before this release. New behavior is not mentioned here. Plain bugfixes (correcting incorrect behavior) are skipped too. Only things that cannot be described as simple "fixing" something are described here. The changes since 4.8 are of interest probably for "advanced" midPoint deployments only. You should at least scan through them, though.

• Checking for conflicts for single-valued items was fixed (strengthened). In 4.8.3 and before, there were situations that two strong mappings produced different values for a given single-valued item, yet no error was produced. (If the item contained the same value that was produced by one of these mappings.) Such configurations are in principle unstable, so this kind of errors should be identified and fixed. Please see bug:MID-9621[] and this commit.

• The default configuration for caching was changed. Currently, only the attributes defined in schemaHandling are cached by default. (Except for the situation when the caching is enabled by cachingOnly property in the read capability.)

• When processing live sync changes that contain only the object identifiers, a more aggressive approach to fetching actual objects was adopted: We now always fetch the actual object, if possible. The reason is that the cached version may be incomplete or outdated.

• The behavior of disableTimestamp and disableReason in the shadow activation container was changed. Before 4.9/4.8.1, these properties were updated only if there was an actual change in the administrative status from something to DISABLED. Since 4.9/4.8.1, both of these properties are updated even if the administrative status is already DISABLED: the disableReason is determined anew, and the disableTimestamp is updated if the status and/or the reason are modified. See bug:MID-9220[].

• Automatic caching of association binding attributes (the "value" side, i.e. valueAttribute in the association definition) is no longer provided. It is recommended to mark them as secondary identifiers.

• The filtering of associations was changed slightly. In particular, even if the required auxiliary object class is not present for the subject, the association values are still shown - if they exist on the resource. (They were hidden before.)

• To address bug:MID-9638[] and bug:MID-9670[] (leaking data via searching objects by filters), the handling of items allowed for search operations was changed.

It is now evaluated not only for the type we are searching for (like RoleType), but for all types whose items are to be used for the search (like UserType for a filter like "give me RoleType referencedBy UserType via `assignment/targetRef`").

The checks are "yes/no" style only, based on the presence or absence of authorizations against specified type and item(s), with appropriate action URIs (read, search, and the new searchBy). No detailed checking for the values is done. E.g. if the search for UserType:name is allowed even for potentially a single user object (via an authorization clause that can provide any number of matching objects, even zero), then the name item can be used for any search concerning UserType or even FocusType objects.

Effects on existing deployments:

1. Some queries allowed previously may now fail because of missing item-searching authorizations. As a quick fix, new (experimental, temporary) searchBy authorization is available to give search access to these items without providing any additional access to data values.

2. Some queries denied previously may now be allowed. This should be quite rare, but possible. It can happen if the original authorization was not applied because of some specific limitations (like roleRelation with no explicit role information), and hence the item/exceptItem part of it was skipped. This is no longer the case.

See commit 609286.

• The effectiveMarkRef item now has value metadata to determine the values' origin. See commit 351d7e.

• The mapping specification in provenance metadata now contains also object type name, association type name, and the shadow tag. See xrefv:/midpoint/reference/support-4.9/expressions/mappings/#_mapping_maintenance_tasks[Mapping Maintenance Tasks], commit 0dd1c0, and commit 8557f5.

• "<a:indexed/>" and "<a:indexOnly/>" annotations - when present but without any value - was interpreted as "false". This was now changed to a more intuitive interpretation (similar to a:object, a:container, etc), where annotation present but without value means "true". Also, "a:container" and other markers were interpreted as "true", even if the value was actually "false". This is now fixed as well.

• Years-old ref-style schema annotations like <r:identifier ref="icfs:uid"/> are no longer supported. They are not used since midPoint 2.0. If you happen to use them in your manually configured resource XSD schemas, please replace them with the supported <r:identifier>icfs:uid</r:identifier> style.

• Support for getting/setting objects embedded in references marked as a:objectReference directly, like LensElementContext.getObjectOld(). This feature was used only internally by midPoint.

• The <xsd:documentation> element in resource schemas is now ignored. It was never used by ConnId connectors, but, in theory, it might be used for manually entered schemas.

• Default target set for mappings emitting multivalue properties is based on provenance metadata, mapping can only remove values, it added.

  • If value has multiple provenances (user entry, or multiple mappings), the mapping removes only its provenance section, value still remains.

Note

The addition of the value metadata at various places of objects means that the objects are larger than in previous versions of midPoint. In a similar way, the shadow caching feature - enabled by default for new installations - will probably increase the size of shadow objects further. All this will probably have an impact on the database size as well as on the runtime performance. (The exact proportions depend on specifics of the deployment.) All these features can be configured - or even turned off in the extreme case - so you can do your own tradeoff between functionality and performance. Moreover, we plan to improve the performance in the forthcoming releases.

Java and REST API Changes Since 4.8

Note	As for the Java API, this section describes changes in midpoint and basic function libraries. (MidPoint does not have explicitly defined Java API, yet. But these two objects are something that can be unofficially considered to be the API of midPoint, usable e.g. from scripts.)

Internal Changes Since 4.8

Note

These changes should not influence people that use midPoint "as is". They should also not influence the XML/JSON/YAML-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.

• Internal APIs were massively changed with regard to passing prismContext object between methods. This object has been statically available for quite a long time. Now it was definitely removed from methods' signatures.

  The official APIs (like midpoint and basic objects) were not touched by this change. However, if you use some of the unofficial or undocumented APIs, please make sure you migrate your code appropriately.

  The change itself is very simple: basically, the PrismContext parameter was removed from methods' signatures.

• Likewise, the internals of prism definitions were changed in 12808d. You should not be affected by this; however, if you use some of the unofficial/undocumented APIs, please check your code.

{% include release-issues.html %}