Incompatible Changes

Previously, you could use the Flowable workflow engine's embedded H2 database for demo and testing purposes. IDM no longer includes this database. Before you use workflow, you must install a JDBC repository.

For more information, see Enable Workflows.

The Activiti workflow engine has been replaced with Flowable. Current workflow definitions will continue to work with the new engine in compatibility mode, but all new workflow definitions must be written for Flowable. For more information, see "Workflow Definition Comparison".

If you are using MySQL for the workflow database, the following apply:

The default log message formatter has changed from ThreadIdLogFormatter to SanitizedThreadIdLogFormatter. The new default encodes control characters (such as newline characters) using URL-encoding, to protect against log forgery. Control characters in stack traces are not encoded. For more information, see Set the Log Message Format.

In previous IDM releases, managed users were granted the openidm-authorized role as a relationship during user creation, as part of the onCreateUser.js script. In IDM 7, users are granted the openidm-authorized role statically, when they authenticate. For more information, see "Authentication and Roles".

The default relationship model for authzRoles and authzMembers has changed in this release. In the default configuration, a user's authzRoles now references only the internal/role resource collection, and not the managed/role. Conversely, an internal role's authzMembers property now references only the managed/user resource collection.

The default schema configuration files have been amended to support this change. The managed/role collection has been removed from the authzRoles property on a managed user object, and the internal/user collection has been removed from the authzMembers property on an internal role object.

Multiple resource collections for a single relationship field are not currently supported with a DS repository. Multiple resource collections will still work with a JDBC repository, for legacy reasons.

The INTERNAL_USER authentication module is no longer provided in the default authentication configuration.

This change means that any scripts you used previously to update internal user passwords in the IDM repository will need to be modified.

Monitoring using Prometheus is no longer achieved with a specific access role. The openidm/metrics/prometheus endpoint is now protected by a basic authentication filter, using credentials set in the resolver/boot.properties file. For more information, see "Monitoring With the Prometheus Endpoint".

Properties stored in the repository with boolean (true/false) values are processed differently from this release. A property value is now considered false if its value is false or null. The value is considered true only if it is true, not if it is null. If you are migrating from a previous IDM release, you might need to adjust your scripts to take this change into account.

effectiveRoles and effectiveAssignments are now calculated in IDM by default, using the new queryConfig property. The old method of using onRetrieve scripts will still work. The new queryConfig property is also available for use with other virtual properties. For more information about effective roles and assignments, see "Effective Roles and Effective Assignments". For more information about queryConfig and virtual properties, see "Virtual Properties".

You can now configure Gzip compression for HTTP responses in conf/jetty.xml. In previous IDM releases, compression was configured in conf/servletfilter-gzip.json. This file has been removed.

IDM 7 supports configurable hashing algorithms.

Enforcing temporal constraints on roles is now achieved through Java, rather than through the onSync-roles.js and postOperation-roles.js scripts. These scripts are still provided in openidm/bin/defaults/script/roles for backward-compatibility.

To use the new Java-based functionality in existing deployments, change the role object in your managed object schema (conf/managed.json), by adding "isTemporalConstraint" : true to the "temporalConstraints" object. For example:

"temporalConstraints" : {
    "description" : "An array of temporal constraints for a role",
    "title" : "Temporal Constraints",
    "viewable" : false,
    "returnByDefault" : true,
    "isTemporalConstraint" : true,
    "type" : "array",
    ...
} 

For information about setting temporal constraints on roles, see "Use Temporal Constraints to Restrict Effective Roles".

The batch configuration for the JMS common audit handler for access logs has changed to support reconnection if the broker becomes unavailable.

For details on the JMS handler configuration, see "Configure the JMS Audit Event Handler".

The default configuration for audit has been changed to no longer have the recon audit topic included by default. It can be enabled by adding the recon audit topic to the topics list in conf/audit.json, for the event handlers you choose.

This change does not affect how auditing reconciliations works, just what the default configuration includes. No action is necessary unless you wish to have auditing on reconciliations enabled on a new installation. For more information, see Query the Reconciliation Audit Log.

As a security precaution, the nativeType for userPassword properties has been changed to JAVA_TYPE_GUARDEDSTRING in all sample provisioner files for the LDAP Connector. If you have customized provisioner files, you should change this property. For example, change:

"userPassword" : {
    "type" : "string",
    "nativeName" : "userPassword",
    "nativeType" : "string",
    ...

to

"userPassword" : {
    "type" : "string",
    "nativeName" : "__PASSWORD__",
    "nativeType" : "JAVA_TYPE_GUARDEDSTRING",
    ...

Previous IDM versions included a global consent setting, in conf/consent.json. This file included a single configuration property, enabled, which determined whether IDM should check any mappings for which consent was enabled and prompt end users for consent.

This global consent setting, and the corresponding consent.json file, have been removed. If you have an existing consent.json file in your configuration, it will simply be ignored.

Consent is now assessed only on a per-mapping, per-object basis. For more information, see "Configure Privacy and Consent".

IDM 7 adds support for the latest version of MySQL Connector/J has been added. If you are using version 8.0 or later, make sure your datasource.jdbc-default.json file includes a setting for the time zone in your jdbcUrl property:

"jdbcUrl" : "jdbc:mysql://&{openidm.repo.host}:&{openidm.repo.port}/openidm?allowMultiQueries=true&characterEncoding=utf8&serverTimezone=UTC",

Also, note the driverClass changed in version 8.0, from com.mysql.jdbc.Driver to com.mysql.cj.jdbc.Driver. The previous driverClass name will still work for now, but should be updated to avoid it displaying a warning when starting up IDM.

The default security protocols for inbound connections to IDM are TLSv1.2 and TLSv1.3. For information on enabling additional protocols, see "Enable and Disable Secure Protocols and Cipher Suites".

Support for the TLSv1.1 protocol has been removed by default.

The address2 attribute has been removed from the managed object schema (conf/managed.json).

The following ICF and connector changes will have an impact on existing IDM deployments that use those connectors: