Skip to content
Permalink
main
Go to file
 
 
Cannot retrieve contributors at this time
81 lines (53 sloc) 3.2 KB

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

  1. OID is permanent, not shared

  2. 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

    1. made globally unique by inclusion of a scope element or domain identifier

  3. mP can generate any other unique id and share with external systems

characteristics that identifies may have or may not have

  1. internal: person registry managed; not shared outside the person registry

  2. unique within IdP namespace

  3. name-based or otherwise recognizable

  4. opaque (not name-based or otherwise recognizable)

  5. 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

  6. not re-assignable (once assigned, a given identifier value will never be reused and assigned to another person)

  7. 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

  1. 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,

  2. 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

  3. How do you handle changes to name-based identifiers

  4. 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

  5. If UID link breaks, mp correlation operation can relink.

You can’t perform that action at this time.