When a change is detected either by using synchronization or reconciliation mechanisms, the change midPoint detects an synchronization event it is categorized into one of the situations. The situation describes how the change relates to the midPoint state regarding the changed resource object (account), user and the midPoint policies. Detected situation by reconciliation or synchronization mechanism is than saved with shadow in midPoint's repository.
The situations are described in the following table.
May happen during ...
The resource object is linked to an appropriate focal object.
Change in account attributes only.
The resource object is linked to two or more focal objects.
Error in IDM business logic or inconsistent database. Should not happen. Do we need this situation?
The resource object has been deleted.
A legal account is manually deleted on the Resource.
The new account A resource object is found on the resource (it exists), IDM midPoint determines exactly one owner for that account in IDM resource object and that owner does not have the account resource object linked (yet).
The account was created on the resource using native administration tools. Initial (incremental) import.
The new account A resource object is found on the resource (it exists) and IDM midPoint cannot determine any owner for the object.
New account was created on the resource using native administration tools and the account has wrong username.
New account created on an authoritative resource (e.g. HR system)
Two or more owners are determined for a single resource object.
An ambiguous account is created manually on the resource, e.g. using a username
The situations deal only with existence or non-existence of resource object (account) and with ownership of the account. In other words it deals only with "links". It does not deal with the " legality " of the account (whether the user should have the account). See Assigning vs Linking page for a more detailed explanation. The situations also does not deal with change in account attributes.
The stations are expressed in the form enumeration (string names) in XML objects. The situations described above are pre-defined in current version of midPoint. More situations may come in the future or the meaning may slightly change in time. The schema will define all the values (enumeration) for the situations and also the meaning of each situation in in-line schema documentation.
The reactions are expressed in a form of URL in the XML files. We expect that more types of reactions will come in the future (e.g. ability to invoke a service) and there even may be plug-in mechanism to create totally custom reactions. Therefore a clean namespacing mechanism is used. As usual in midPoint, we rely on existing XML mechanism for that: URLs.
The built-in reactions are all located in the midPoint namespace:
MidPoint is using the following algorithm to determine a situation:
- If the resource object is deleted then the situation is deleted.
- Resource object owner is looked up. The owner is an object that has a link to this resource object. If an owner is found then the situation is linked.
- Correlation and confirmation expressions are used to determine a potential owner for the resource object. If any potential owners are found the situation is unlinked or disputed.
- The situation is unmatched.
Following table summarizes the differences among situations from the point of view of detected account operation and the number of owners (or potential owners).
Detected operation on account
Link exists (user has account)
Link does not exists, correlation&confirmation found users
2 or more