170 likes | 281 Vues
This primer, presented at Internet2's CAMP in June 2002, outlines the critical role of identifiers in middleware infrastructure. It discusses the complexities and policies surrounding identifiers, including their types, characteristics, and the importance of authoritative sources. Key issues such as permanence, relationships among identifiers, and the mapping between different systems' identifiers are explored. The document emphasizes the need for effective identity management and reconciliation processes to ensure seamless interoperability and data integrity across various platforms.
E N D
Technical Primer: Identifiers Internet2 Base CAMP Boulder, Colorado June, 2002
Identifiers – Why so important? • Foundation of middleware infrastructure – if you can find it, it will receive services. • Policy laundry service – clean out the fuzz bunnies. • Crossing borders – mapping from one system’s identifier to another. • Share the wealth – the right identifier may work across multiple systems. • Abuse the wealth – one identifier may enable the activation of additional identifiers.
Identifiers – Key Issues • Policy • Authoritative source • How formed • Permanence • Where used • Relationships • Mapping between/among subject and subject’s identifiers • Dependencies between identifiers
Identifier Characteristics • Lucent or Opaque? (human readability) • For human ease of use, names are good • Machines can handle numbers, big numbers • Consider privacy issues • Provisioning – who/what/when • Central vs. distributed assignment • Resolving the identifier to the human • Persistence • Permanent? • Reassignable (when)? • Revokable?
Identifier Types • Unique Universal Identifier (uuid) • Primary internal identifier, centrally provided • Human unfriendly • Assigned to all current active users • Non-revokable, non-reassignable • Linked to by all other identifiers
Identifier Types • Person Registry ID • Used to resolve identity among systems • Opaque, centrally administered, persistent, big • All affiliates should have a registry ID • Account login, netid • Often the same – provide access to electronic resources • Lucent • Authentication required for ownership • Preferable to have central provisioning
Identifier Types • Social Security Number • It was such a great identifier (persistent, centrally provisioned) but… • Legal restrictions to use • Not applicable to foreigners • Email address • Typically human-friendly • Especially helpful if centrally provisioned • May use in combination with email aliases
Identifier Types • Departmental IDs with enterprise scope • Library cards, ID cards • Policies require scrutiny • Helpful if linked to uuid • Pseudonymous IDs • Unique, opaque identifier to ensure privacy to external world • Administrative system IDs • Employee IDs, Student IDs, etc. • Typically centrally assigned • May have competing policies
Inventory of Identifiers • Scope …who issues, what populations, resources used for, entities, policy and enforcement • Operational issues … reassignment, directory access keywords, user or machine-assigned, proof of identity, change requests • Interrelationships … policies re. use of central authentication identifier, synchronization of authentication identifiers, assignment to all affiliates, prerequisite identifiers
Identifier Mapping For each identifier • Map to functional needs • Establish key characteristics • Document relationship among identifiers • Identify policy issues • Document data flows into/among identifiers • Fix – or acknowledge – problems
Identity Management - Reconciliation • The million dollar question: Does this person already exist? • Map incoming attributes to existing attributes • Incoming Employee ID = existing employee ID? • Incoming SID = existing SID? • Incoming SSN = existing SSN, existing SID, previous SID? • If yes matching identifier, still check for (dob + gender) match • If no matching identifier, look for (dob + gender + name) match
HR fac/staff; empID SIS student; SID FIS faculty; SSN Uniquid accounts; unix ID IDcard photos; ISO Telecom phone locn phone # Registry Identifier Mapping • Distinct sources for distinct roles • Unique identifiers for each system • Blending together to build a CU Person • Generating a unique directory entrydn: uuid=123456789,ou=people,dc=colorado,dc=edu CU Person uuid
Identifier mapping results • Policy regarding registry uuid, directory dn • Automatically generated for each new affiliate • Permanent, non-revokable, non-reassignable • Public • Policy-based identity reconciliation logic • SIS and HR are the only trusted identity sources • HR has precedence over SIS for SSN • Identifiers not guaranteed across systems (dob, gender) • Source system identifiers must map to uuid
Identifier puzzlers • Resolving reconciliation exceptions • Coordination among system/data owners • Correction process • Gathering identity attributes from ‘external’ affiliates • Coordinating policies • Identity interoperability among technologies