Person Identifiers
Revision: 01, (2021-04-09)
Self-link: https://github.internet2.edu/api-schema/person
Editor: Keith Hazelton, hazelton@internet2.edu
Issues and Observations
*Person identifier handling in COmanage, Grouper, midPoint, LDAP, and AD
identifier characteristics: Definitive statement for HE and Research: https://wiki.shibboleth.net/confluence/display/CONCEPT/NameIdentifiers
Grouper
~ does have its own internal-only identifier
~ identifier is a tuple, sourceID + personID from that source
~ enter ePPN, or link in email for new ppl being added
~ id to label person in system, but also identifiers for looking them up: email, name,….LoginID
~ id and identifier (anything that can uniquely identify a person
~ 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 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
-
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
characteristics that identifies may have or may not have
-
internal: person registry managed; not shared outside the person registry
-
unique within IdP namespace
-
name-based or otherwise recognizable
-
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
-
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
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? 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 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
-
If UID link breaks, mp correlation operation can relink.