Skip to content
Permalink
7ea2aa52bc
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
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.