1. Directory Design: Campus Identifiers and Namespace Tom Barton University of Chicago

2. CAMP Directory Workshop Feb 3-6, 2004 Copyright Tom Barton 2004. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

3. CAMP Directory Workshop Feb 3-6, 2004 If core middleware is plumbing, this talk is about how to really understand the sewage it transports

4. CAMP Directory Workshop Feb 3-6, 2004 Architectural decision factors Ability to execute Technique Mission

5. CAMP Directory Workshop Feb 3-6, 2004 What we’re trying to accomplish  Reduce burden on end users to access online services  Reduce burden on IT organizations to operate multitude of online services  Increase security  Enable online service for our constituents earlier in their affiliation with us, wherever they are, and forever  Participate in new, inter-organizational, collaborative architectures

6. CAMP Directory Workshop Feb 3-6, 2004 Terminology  Identity: set of attributes about and identifiers referring to a person. Operationalized as a “person object”.  Authentication: process used to associate a user with an identity. Often a login process.  Authorization: process of determining if policy permits an intended action to proceed.  Customization: presentation of user interface tailored to user’s identity. Subsumes personalization.

7. CAMP Directory Workshop Feb 3-6, 2004 What identity management is  Integration of information about people (and other actors) from multiple sources  Processes that transform source data, maintain information about assigned information resources, derive affiliation information, and place resultant data where it can be of use  Locus for implementation of policies concerning visibility and privacy of identity information and entitlement policies

8. CAMP Directory Workshop Feb 3-6, 2004 It’s identity management, silly! Because an authentication process binds a person with an identity, and Because the level of assurance of the authentication process together with the attributes of that identity form the basis for access to be granted the person, It Follows That access control effectiveness is limited by identity management practice. Components of the whole access management system: 3.authentication 4.authorization 1.identity management 2.credential distribution

9. CAMP Directory Workshop Feb 3-6, 2004 Comparative service architectures Stovepipesilo Stovepipe (or silo): Application performs its own authentication and consults its own database for authorization and customization attributes. application authN attributes groups

10. CAMP Directory Workshop Feb 3-6, 2004 Comparative service architectures  Integrated  Integrated: Suite of applications refer authentication to and obtain attributes for authorization and customization from common infrastructure services. application 1 authentication service attribute/group service application N

11. CAMP Directory Workshop Feb 3-6, 2004 Comparative service architectures  Stovepipes are run by separate offices –Environment is more challenging to users, who may need to contact each office to arrange for service and remember several sets of credentials –Any life cycle management of service specific resources is undertaken by each service specific office independently –Per-service identifiers and security practices make it more difficult to achieve a given level of security across the enterprise

12. CAMP Directory Workshop Feb 3-6, 2004 Comparative service architectures  Common identity management processes are coordinated by a central office –Attributes known by the organization about a member can be integrated and made available to applications, easing the burden on end-users and on IT shops –Automated & consistent life cycle resource management becomes possible across all integrated applications –Common identifiers across integrated applications helps make a more secure user environment

13. CAMP Directory Workshop Feb 3-6, 2004 Core middleware for an integrated architecture

14. CAMP Directory Workshop Feb 3-6, 2004 Typical uses  Provisioning & run-time authentication and authorization for common “baskets” of services: email (reading & sending), calendar, shell & cluster accounts, network access services, myriad web apps, LMS, library databases, home directories,….  Online account initialization & self-administration  Provisioning associated IT operations with identity data for their infrastructure  Distributing management of identity data across authoritative sources, manual or automated, central or distributed

15. CAMP Directory Workshop Feb 3-6, 2004 Identifier discovery  First cut black box analysis of what’s to be built  Core middleware will convey identity information from authoritative sources to applications, so … –Find out who assigns what identifiers to which constituencies for what purposes –Find out which applications or services use which identifiers and are intended to serve which constituencies –Make the rounds of IT shops, larger ones first. Ask what they do and what their top issues are  Assess mission, ability to execute, & existing technique

16. CAMP Directory Workshop Feb 3-6, 2004 Two identifier survey matrices  ID mapping table –Columns: ID name, Early Harvest equivalent, primary use, characteristics, who assigns, who gets one, where stored, format –Characteristics: lucency (vs. opacity), persistence (revokable?, reassignable?), unique within, intelligence (subfields?), granularity, extensibility, visibility

17. CAMP Directory Workshop Feb 3-6, 2004 Abbreviated ID mapping table http://middleware.internet2.edu/earlyadopters/identifier-mappings/ Fundamental ID Who Assigns? Who Gets One? idCentral ITPeople universal_userIDCentral ITPeople uidguest registrarsguests emailCentral ITPeople clusterIDCentral ITShell account opt-ins sisIDRegistrarStudents & instructors hrsIDHRStaff frsIDControllerHolders of budget roles adsIDMarketing & AdvGraduates, other donors aprIDProvostFaculty operatorIDControllerERP security principals patronIDLibraryLibrary patrons

18. CAMP Directory Workshop Feb 3-6, 2004 Characteristics example  sisID characteristics –Government assigned SSN or assigned by Registrar –Opaque –Persistence: revokable & reassignable –Unique among all values of sisID at one time –Intelligence: no subfields –Granularity: one per person –Not extensible –Visibility: some limits on when displayed or presented  SSN on campus – effectively a locally assigned identifier! –Foreign students –many points of operational authority –sisID is NOT named “SSN”!

19. CAMP Directory Workshop Feb 3-6, 2004 Constituencies & services matrix  For each constituency you discover, note the different identifiers assigned to them  For each service you discover, note the identifiers it does or might use for each constituency  Keep a running legend of identifiers discovered by this process  Look for –Gaps between present and desired service levels –Complexity of present environment, opportunities for simplification

20. CAMP Directory Workshop Feb 3-6, 2004 Constituencies & services matrix legend: ISO, UCID, CNetID, StuID, legend: UCHID, Personal info, RegID, Other studentsfacultystaffalumsexpected who has what, or will have, that we get I,U,(C),S, P,R I,U,(C), P,R (U),(C),P,R Payroll U,O(acf2) Student systemU,C,S Provost ops O(ssn) Purchasing CC Alumni community U,C Financials O(acf2) Credit UnionUUU Time/Attendance U,P

21. CAMP Directory Workshop Feb 3-6, 2004 Constituencies & services matrix legend: ISO, UCID, CNetID, StuID, legend: UCHID, Personal info, RegID, Other studentsfacultyalumshospitalpatronsguests who has what, or will have, that we get I,U,(C),S, P,R I,U,(C), P,R (U),(C),P,R (C),H,P, R (I),(C),(O) ? C,R,(O ) phonebookU,C,S,PU,C,PPH,P emailCCC net accessCCCC,HCC labsI,C ? C lib DBsCC ?C,HC ? LMS, eReservesCC web servicesU,C,R C,H,R CNet siteI,U,C,P U,C,PC,O

22. CAMP Directory Workshop Feb 3-6, 2004 Identifier discovery redux  How hard is this environment for end-users?  Should you reduce the number of namespaces in use?  Is simplification worth the effort? –Unification of namespaces can be painful & requires serious organizational cooperation and commitment  More important than the technical details is the establishment of ongoing relationships between architect and people who assign and design uses for fundamental identifiers.

23. CAMP Directory Workshop Feb 3-6, 2004 PS: Personal Identifiers Who maintains name, birthday, SSN? 1.Registrar 2.Human Resources 3.Bursar 4.ID Office 5.Law School 6.University College 7.Library 8.Regents Online Degree Program 9.Central IT 10.Controller 11.Marketing & Advancement 12.Academic Personnel Records 13.Telecom/Network Services 14.Intensive English for Internationals This is an irrational business practice!

24. CAMP Directory Workshop Feb 3-6, 2004 Source systems: identifier semantics  Affiliations –Which source systems define which affiliations? How? –How do constituents become engaged in their various affiliations with the U? How disengaged?  Associated attributes –What other attributes of value to online services are maintained in which source systems? –How are they maintained, for what purposes? Are they reliable?  Metadata –(De-)Assignment process; persistence; visibility; versions;… –What encumbrances/obligations/policies pertain? –Updatable (in source system)? Forever iterate over these considerations as more applications are added

25. CAMP Directory Workshop Feb 3-6, 2004 Registry identifiers classes  Fundamental IDs –Permanent, unreleased registry ID –Permanent pvid? –Versions? –Source & consumer foreign keys: crosswalk (Rosetta Stone) All is hidden from view  Personal IDs … –External IDs: name, bday,... –Q&As –Account init code –Answer “Is this a new person?” –Provide unique-ification

26. CAMP Directory Workshop Feb 3-6, 2004 Registry identifier classes  Authoritative identifiers –Username(s)? –Attributes for provisioning processes –Specific to consuming technology? –Specific to consuming org?  Affiliations –Common or “major” values derived from authoritative sources  Affiliations … –Course, program, organization related identifiers –Life cycles of affiliations? –Notable subclasses of major affiliations? –Group memberships?  Multiple namespaces? –For registry objects? –For consumer systems?

27. CAMP Directory Workshop Feb 3-6, 2004 Consumer identifier issues  Fundamental IDs –Choice of RDN (LDAP consumers only) –Store/use pvid? As a key field? –Persistence, visibility, opacity, …  Potential interaction with privacy policy  Representation of attributes –Determined by application use cases –Consumer specific selection & transformation? –Overloading issues:  cn: name of person, name of group, name of service account, name of …  uid: orthogonal sets of usernames? All is potentially exposed

28. CAMP Directory Workshop Feb 3-6, 2004 Service - identifier boundary conditions  Ability to use or be provisioned with a user identifier authoritatively located in the enterprise directory is a requirement for integration into this architecture  Service requirements determine representation of attributes  Service requirements may determine sources of authority for attributes, and hence operational requirements for identity management infrastructure

29. CAMP Directory Workshop Feb 3-6, 2004 Stresses on a common username space  Least common denominator format requirements  Number of persons assigned one (prospects, alums, parents, sibs, patrons, donors?) –Will all the good ones be taken?  Persistence - forever?  Shared administration of portions of user namespace might drive adoption of orthogonal name subspaces –Closely affiliated org (hospital?) –Guest registration