Reconcile with case-insensitive data stores
IDM is case-sensitive, which means that an uppercase ID is considered different from an otherwise identical lowercase ID during reconciliation. Some data stores, such as PingDS (DS), are case-insensitive. This can be problematic during reconciliation, because the ID of the links created by reconciliation might not match the case of the IDs expected by IDM.
If a mapping inherits links by using the links
property, you do not need to worry about case-sensitivity, because the mapping uses the setting of the referred links.
Alternatively, you can address case-sensitivity issues with target systems in the following ways:
-
Specify a case-insensitive data store. To do so, set the
sourceIdsCaseSensitive
ortargetIdsCaseSensitive
properties tofalse
in the mapping for those links. For example, if the source LDAP data store is case-insensitive, set the mapping from the LDAP store to the managed user repository as follows:"mappings" : [ { "name" : "systemLdapAccounts_managedUser", "source" : "system/ldap/account", "sourceIdsCaseSensitive" : false, "target" : "managed/user", "properties" : [ ...
You might also need to modify the connector configuration, setting the
enableFilteredResultsHandler
property tofalse
:"resultsHandlerConfig" : { "enableFilteredResultsHandler":false },
Do not disable the filtered results handler for the CSV file connector. The CSV file connector does not perform filtering. Therefore, if you disable the filtered results handler for this connector, the full CSV file will be returned for every request. -
Use a case-insensitive option in your managed repository. For example, for a MySQL repository, change the collation of
managedobjectproperties.propvalue
toutf8_general_ci
. For more information, refer to Case insensitivity for a JDBC repo.
In general, to address case-sensitivity, focus on database-, table-, or column-level collation settings. Queries performed against repositories configured in this way are subject to the collation, and are used for comparison.