1. Campus Authentication: Identification Process and Related Policy Tom Barton University of Chicago & Internet2

2. 4 June 2003CAMP 2 Copyright Thomas J. Barton 2003. 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. 4 June 2003CAMP 3 Outline Identity management framework Roundup of ID management policy & process issues Sidebar on I&A Remote account initialization Jump in with questions & comments!

4. 4 June 2003CAMP 4 It’s identity management, stupid! 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. Three components of the whole system: 1.authentication process 2.identity management 3.credential distribution Keith’s talk main focus minor focus

5. 4 June 2003CAMP 5 What identity management is Integration of information about constituents (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. NB: Can still speak of identity management regardless of how extensively these are done.

6. 4 June 2003CAMP 6 What effective identity management does Simplifies what users must know to access to online services. Enables IT organization to efficiently provide multitude of online services. Increases security. Enables online service for constituents earlier in their affiliation with us, wherever they are, and forever. Enables participation in new, inter-organizational, collaborative architectures.

7. 4 June 2003CAMP 7 Core middleware for an integrated architecture

8. 4 June 2003CAMP 8 Source system identifiers Personal & fundamental identifiers –Feed the join process Affiliations –Which source systems define which affiliations? How? –How do constituents become engaged in their various affiliations with the U? How disengaged? Associated attributes –Other attributes of value to online services. –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

9. 4 June 2003CAMP 9 Registry identifiers Fundamental identifiers –Permanent guid. –Permanent pvid? –Versions? –All source & consumer identifiers to enable source join & consumer crosswalk. Derived identifiers –Username(s). –Attributes for provisioning processes. –Consumer specific? Affiliations –Course, program, org related identifiers & objects. –Group memberships. –Derived. Namespace issues –Multiple namespaces?  For registry objects?  For consumer systems? –Overloading. –Downstream format requirements. All is hidden from view

10. 4 June 2003CAMP 10 Consumer identifiers Fundamental identifiers –Persistence, visibility, opacity, … Potential interaction with privacy policy –Store/use pvid? –Choice of naming components (LDAP only). Representation of attributes –Application use cases –Overloading & namespace collision. E.g.s: cn: name of person, name of group, name of … uid: orthogonal sets of usernames? –Consumer specific selection & transformation All is potentially exposed

11. 4 June 2003CAMP 11 Service identifiers Ability to use or be provisioned with a user identifier derived in the metadirectory is a requirement for integration into this architecture. Attribute schema –Conventions for syntax & semantics Stresses on a common username space: –Least common denominator format requirements. –Number of persons assigned one (alums?, parents?, sibs?, patrons?, donors?). –Duration of assignment: forever? –Potential for shared administration of portions of username space might drive creation of orthogonal namespaces. Eg, OS usernames, uids, gids w/ nss-ldap. University “guest” registration. Username & related namespace issues

12. 4 June 2003CAMP 12 Identifier Discovery Identify the identifiers, starting with key source systems and prevalent or important services. –ID Mapping Table columns: ID name, Primary Use, who assigns, who gets one, where stored, format. characteristics: opaque/transparent, lucent?, reassignable?, revokable?, unique within. More important than the technical details is the establishment of ongoing relationships between architect and people who assign and use fundamental identifiers.

13. 4 June 2003CAMP 13 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

14. 4 June 2003CAMP 14 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!

15. 4 June 2003CAMP 15 Additional policy & process issues How will the University operate its identity management infrastructure? –What balance between centralized and distributed operation? Registry – singular, centralized function. Consumers – high degree of distribution possible. Registration Authorities – small number?? –Who may have which role with what authority & obligations? –Leverages & extends existing data administration policies & processes, or begs if those are insufficient. –Highly cross-functional activity demanding organizational flexibility.

16. 4 June 2003CAMP 16 Additional policy & process issues What entitlements should attend each type of affiliation? –“Major” affiliations: student, faculty, alum, … Possibly former or recent student, faculty, …? –“Minor” affiliations: in course 123, in department X, in degree program Y, occupant of building Z, … –What processes should determine entitlements for each affiliation? How should affiliations be structured?

17. 4 June 2003CAMP 17 Additional policy & process issues Who should be issued a credential? What assurance level should authentication for each constituency achieve? What constraints may pertain to each? –Applicants (student, faculty, staff) –Admitted students, accepted faculty or staff –Alums –Parents –Library patrons –Guests: visiting academics, conference attendees, hotel guests, arbitrary “friends”, …

18. 4 June 2003CAMP 18 Identification & Authentication (I&A) Often thought of as the process used by a Registration Authority to validate a person’s identity, issue appropriate credential, and distribute it to the person, as in “initial I&A procedure”. Every PDP’s access control decision depends on a chain of trust whose first link is I&A. Net assurance is proportional to trustworthiness of the weakest link. Work in progress at OMB & NIST to develop standards for “level of assurance” for various I&A methodologies. Watch http://www.cio.gov/eauthentication/

19. 4 June 2003CAMP 19 Identification & Authentication (I&A) Not all users are likely to need the same level of assurance. Assurance requirements for some users may change over time. Not all relying parties will trust credentials issued by just any University, regardless of self-asserted level of assurance.  Take the “initial” out of “initial I&A”. The lifecycle of a binding between a person and an identity may touch I&A procedures more than once.  N.B. an identity may well contain more than one credential. Extreme e.g.: “rational identity management” scenario…

20. 4 June 2003CAMP 20 (Remote) account initialization The problem: how to reasonably do initial I&A without requiring physical presence of the person. –Past experience at U Memphis made it undesirable to rely solely on information the remote person already knows (birthdate, SSN). –Secondary requirement: autonomously handle lost username or password for remote user. –Interim solution: the procedure about to be described. –Long term solution: a less than fully resolved aspect of “rational identity management”.

21. 4 June 2003CAMP 21 Account initialization: interim method Crux: USMail a rather opaque one-time secret, early in the process of engagement with the University. –Use guid generator to produce an “account initialization code”. Example: 1951 K21V 674I V106 0L03 Resembles a license code. Difficult to memorize or guess, easy to transcribe. –Code, birthday are used to identify person on an identity management web site and enable them to claim username, select password, setup security questions & email. –Currently in use for new faculty, soon for admitted students.

22. 4 June 2003CAMP 22 BoF Bait??