Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.

Situations

The situations are described in the following table.

Situation

Description

Examples

May happen during ...

Possible Usual
reactions

linked

The resource object is linked to an appropriate focal object.
E.g. the account is linked to a user.

Change in account attributes only.
Redelivery of a change notification that was already delivered and processed.
Reconciliation found not mismatch for this account. Reconciliation

  Synchronization

modifyUser

collision

The resource object is linked to two or more focal objects.
E.g. The account is linked to two or more IDM users.

Error in IDM business logic or inconsistent database. Should not happen. Do we need this situation?

Reconciliation
Synchronization

 

deleted

The resource object has been deleted.
E.g. The account existed on the resource, but it has been deleted.

A legal account is manually deleted on the Resource.

Reconciliationunlink
Synchronization deleteFocus
unlinkAccountinactivateFocus
addAccount addShadow

unlinked

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).
E.g. New account is found on the resource, an owner (midPoint user) is found by using a correlation expression.

The account was created on the resource using native administration tools. Initial (incremental) import.

Reconciliationlink
Synchronization deleteShadow
linkAccount inactivateShadow deleteAccount
disableAccount

unmatched

The new account A resource object is found on the resource (it exists) and IDM midPoint cannot determine any owner for the object.
E.g. New account is found on the resource, it is (obviosly) not linked to any user and correlation expression returns no candidate owners.

New account was created on the resource using native administration tools and the account has wrong username.
Initial import.

Reconciliation
Synchronization

addUser
deleteAccount
disableAccount

disputed

New account created on an authoritative resource (e.g. HR system)

addFocus
deleteShadow
inactivateShadow

disputed

Two or more owners are determined for a single resource object.
E.g. New account is found on the resource and two or more owners are found for it users are returned by correlation expression.

An ambiguous account is created manually on the resource, e.g. using a username smith that matches surname of several users

ReconciliationdeleteShadow
Synchronization inactivateShadow

deleteAccount
disableAccount

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.

Situation Names

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.

Reaction URLs

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:

...

The Algorithm

MidPoint is using the following algorithm to determine a situation:

  1. If the resource object is deleted then the situation is deleted.
  2. 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.
  3. 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.
  4. The situation is unmatched.

Situation Overview

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

 

 

0

1

2 or more

ADD

linked

unmatched

unlinked

disputed

MODIFY

linked

unmatched

unlinked

disputed

DELETE

deleted

deleted

deleted

disputed

deleted

See Also