Affects Version/s: OpenIDM 2.1.0
Fix Version/s: None
Component/s: Module - Provisioner framework
Environment:Solaris, openidm 2.1.x (built from trunk)
java version "1.6.0_38"
Java(TM) SE Runtime Environment (build 1.6.0_38-b05)
Java HotSpot(TM) Server VM (build 20.13-b02, mixed mode)
I think there is still some brokenness here, relating to the fix for
OPENIDM-456. The documentation says that :
sourceIdsCaseSensitive (boolean, default TRUE)
targetIdsCaseSensitive (boolean, default TRUE)
If it is false, should store _id in lower case in the links table, which it does, but even with a provider that uses the targetIdsCaseSensitive, you cannot ask for http://localhost:6750/openidm/system/pclan/account/testuser or http://localhost:6750/openidm/system/pclan/account/TESTuser from the provider, so only one of these works (the one that matches the case in the provider - otherwise openidm used the wrong case, and the provider says not found, resulting in an incorrect UNASSIGN case).
In the log, it shows /system/pclan/account/testuser (the lower case) but if if the user is stored in mixed case on the provisioner data source, so while it should store a lower case _id in the links table, the LDAP provider is expecting native case, the logged path /system/pclan/account/testuser path will not work only (/system/pclan/account/TESTuser) works.
openidm being case insensitive when comparing links, does not make the openicf provider ignore the case when requesting data from the provider when requesting said links, so even if it links by a case insensitive identifier, it needs to keep the original case as provided by the openicf provider, or make the provider also case insensitive for queries ?
the test for
OPENIDM-456 is to create a user in a ldap provisioner using targetCaseInsensitive with one case, and request the data with another case, it should work it doesn't. It only appears to work now, as the defaults for all test data are lower case.
to expose this bug, after an initial CREATE phase, rename some of the test users in the destination server to differ to be not all lower case, such is the default.. then those users will be seen as UNASSIGN-ed .. if the sync is really case insensitive, changing the destination case should not matter
this is particularly exposed when the policy is only set to UPDATE, if the policy is CREATE, then the users will be made with matching case and it will work, again hiding the case insensitivity problem (as UPDATE's subsequent to the CREATE will match case and work - although a case insensitive provider will ignore case in an LDAP query, it will usually store the case as provided)
the use case is to match accounts only with UPDATE, based on uid that differs in case between source and target..