thoughts.adoc
Proposed event-driven approach to person registry identifier assignment
Each SoR record fires an event when it detects a person previously unknown to the SoR. The event label is something like 'noticedNewPerson' and the message will include the {Sorid} and an SoR-generated unique identifier for that person.
MVService: create subscriber to 'noticedNewPerson'; Its only function is to generate a new internal identifier, link it to the Sorid-assigned unique identifier and persist that info.
Hypothetical Precondition
A person was just now added to a System of Record, midPoint has not yet processed this, so has no record of their existence
Process A: A Grouper admin wants to manage groups for the new person . Grouper admin types something they know about the person (a name or email or other identifier) into Grouper .. Case 1: Subject lookup—not found. What happens then? .. Case 2: Person is found in subject source. What identifier is used when adding them as a member to a group? … What manages getting subjects into the subject source … How does midPoint associate this group member with a know user?
"Solutions and tradeoffs"
-
Have Grouper subject source be provisioned by midPoint;
-
Consequences: Grouper subject search will fail until new person appears in subject source
-
-
Have ID Match always return an identifier for the queried person
-
works for cases where ID Match can definitively match a known identity or definitively be recognized as new, and return the identifier in either case
-
If the result is multiple candidate matches that require human resolution, Id Match does not immediately return an identifier
-
Fix: Have ID Match assign a new identifier to the person in question and return immediately while starting the identity resolution workflow
-
Consequence: If a match with an existing user is eventually found, an identifier correction needs to take place
-
-