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 address Typically human-friendly Especially helpful if centrally provisioned May use in combination with 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

Managing identifiers Preparation through understanding

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

Identifier Map NameUseCharsNotesWho assigns Who receives WhereFormat/ Example Unix loginAccount, modem, labs Reassign, Revoke, Human Multi-sys admin, Revoke if inactive affil ITS, Sysadmins Active fac, staff, students, sponsors Indv servers, uniquid 8 char alpha- numeric Vaughan SIDSIS identifier Non- reassign Revoke Unique sis SSN else 9N Change allowed Registrar or system Students Incl cont ed SIS9N SSNFormer HR ID, FIS ID, ememo ID Non- reassign, non-revke, Unique USA Replaced by emplid in HR US GovAll rcvg taxable $$ in US PS HR, FIS, SIS, Buff1Card 9N

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

Registry Identifier Mapping Distinct sources for distinct roles Unique identifiers for each system Blending together to build a CU Person Generating a unique directory entry dn: uuid= ,ou=people,dc=colorado,dc=edu HR fac/staff; empID SIS student; SID FIS faculty; SSN Uniquid accounts; unix ID IDcard photos; ISO Telecom phone locn phone # 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

Discuss!