[midPoint] Strange behavior during reconciliation

Дорофеев Илья i.dorofeev at solarsecurity.ru
Fri Feb 19 15:22:18 CET 2016


Hi guys,

I'm currently exploring how the reconciliation works. The one interesting thing I've ran into is the code below found in ReconciliationProcessor.reconcileProjectionAssociations method (lines 490-497):
if (shouldBeMapping.getStrength() != MappingStrengthType.STRONG && (!areCValues.isEmpty() || hasStrongShouldBeCValue)) {
   // weak or normal value and the attribute already has a
   // value. Skip it.
   // we cannot override it as it might have been legally
   // changed directly on the projection resource object
   continue;
}

This code postulates that I cannot provision values (which are associations here in fact) produced by mappings of normal strength (which is default) if a resource object already has a non-empty list of associations. It means that if some midpoint policy of normal strength requires an account to have the associations with the entitlements A, B and C, and this account is actually associated only with A (say, B and C are removed from the account directly on the resource), then the reconciliation won't restore missing associations with B and C. Is this the intentional behavior or is it a bug? In my view, this code only makes sense for single-valued attributes when we don't want to override the values set outside the IdM. In case of multi-valued attribute, no overriding is actually happens because we only add values but do not replace them.

__________________________

Ilya Dorofeev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20160219/a7e8db99/attachment.htm>


More information about the midPoint mailing list