From 7ea2aa52bc39166d036322a3c669e59668d92ae4 Mon Sep 17 00:00:00 2001 From: Keith Hazelton Date: Wed, 12 May 2021 11:35:29 -0500 Subject: [PATCH] Update person-identifiers.adoc --- person-identifiers.adoc | 79 +++++++++++++++-------------------------- 1 file changed, 28 insertions(+), 51 deletions(-) diff --git a/person-identifiers.adoc b/person-identifiers.adoc index dadd53a..0d0671f 100644 --- a/person-identifiers.adoc +++ b/person-identifiers.adoc @@ -20,8 +20,6 @@ COmanage, Grouper, midPoint, LDAP, and AD identifier characteristics: Definitive statement for HE and Research: https://wiki.shibboleth.net/confluence/display/CONCEPT/NameIdentifiers -. unique across the IdPs population Y/N - *Grouper* ~ does have its own internal-only identifier + @@ -32,73 +30,52 @@ identifier characteristics: Definitive statement for HE and Research: https://wi ~ Grouper external users is where the ePPN for a new member + *COmanage* - In general, a multi-values list of identifiers paired with a source identifier; there is a non-shared internal ID - Grouper: - - Refereence ID: two match modes: Match up front; config. COmanage to match based on RefID. registry gets a ref id, and stores it - - Match API backend is just a database that understands ref id and sourceID - - provision to LDAP, point Grouper subject source at LDAP; - + +~ In general, a multi-values list of identifiers paired with a source identifier + +~ there is also a non-shared internal ID + +~ Reference ID: two match modes: +~~ Match up front; configure COmanage to match based on Reference ID +~~ Registry gets a ref id, and stores it +~ Match API backend is just a database that understands ref id and sourceID +~ provision to LDAP, point Grouper subject source at LDAP; +~ COmanage has identifier modules to generate identifiers with the desired characteristics; + +*midPoint* -mp: OID is permanent, not shared name is a name-based identifier (other could be added), can change if needed, could be a campus id that users tend to know -- globally unique by inclusion of a scope element or domain identifier -- mP can generate any other unique id and share with external systems +. OID is permanent, not shared +. name is a name-based identifier (other could be added), can change if needed, alternatively could be a campus id that users tend to know +.. made globally unique by inclusion of a scope element or domain identifier + +. mP can generate any other unique id and share with external systems -. name-based or otherwise recognizable? Y/N -internal id: No -. opaque (not name-based or otherwise recognizable) Y/N +*characteristics that identifies may have or may not have* -- permanent (changes are rare or non-existent) -can be merged if necessary. +. internal: person registry managed; not shared outside the person registry -- re-assignable (once assigned, a given identifier value will never be reused and assigned to another person) +. unique within IdP namespace +. name-based or otherwise recognizable -- pairwise (formerly called targeted): A person has a different identifier for each service or resource provider with which they interact +. opaque (not name-based or otherwise recognizable) +. permanent (changes are rare or non-existent); can be scenarios where two permanent ids are consolidated if it is determined that both refer to same person -. What is the primary, wholly internal person identifier in your package? +. not re-assignable (once assigned, a given identifier value will never be reused and assigned to another person) + +. pairwise (formerly called targeted): A person has a different identifier for each service or resource provider with which they interact -COm: identifier modules to generate identifiers with the desired characteristics; KeithL: If you make a REST call: here's user, get the OID, use that in the actual REST call . What identifier(s) do you expose to other packages? Internal ID plus tuple source/identifier generate anything you want, configurable; DO NOT USE OID; mP API is a case where you could use OID, -- Do you maintain a crosswalk between each external system identifier and your internal identifier? +. Do you maintain a crosswalk between each external system identifier and your internal identifier? correlation rule: connector says how the id in system maps to id in mP; midPoint maintains link over subsequent change . How do you handle changes to name-based identifiers -- -connectors can work w opaque: UID (used to link to the midPoint user, and another identifier, perhaps name based; mP can update the name identifier - -If UID link breaks, correlation can relink. - - -- - - - -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" +. connectors can work w opaque ids like mP UID (used to link to the midPoint user, user likely has another identifier, perhaps name based; mP can readily update the name identifier -. Have Grouper subject source be provisioned by midPoint; -.. Consequences: Grouper subject search will fail until new person appears in subject source +. If UID link breaks, mp correlation operation can relink. -. 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