Campus Authentication: Identification Process and Related Policy

Tom Barton

University of Chicago & Internet2

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

4 June 2003 CAMP 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 June 2003 CAMP 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 process2. identity management3. credential distribution

Keith’s talkmain focus

minor focus

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

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

4 June 2003 CAMP 7

Core middleware for an integrated architecture

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

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

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

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

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

• More important than the technical details is the establishment of ongoing relationships between architect and people who assign and use fundamental identifiers.

4 June 2003 CAMP 13

Abbreviated ID Mapping Tablehttp://middleware.internet2.edu/earlyadopters/identifier-mappings/

Fundamental IDFundamental ID Who Assigns?Who Assigns? Who Gets One?Who Gets One?

id Central IT Peopleuniversal_userID Central IT Peopleuid guest registrars guestsemail Central IT PeopleclusterID Central IT Shell account opt-inssisID Registrar Students & instructorshrsID HR StafffrsID Controller Holders of budget rolesadsID Marketing & Adv Graduates, other donorsaprID Provost FacultyoperatorID Controller ERP security principalspatronID Library Library patrons

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

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

4 June 2003 CAMP 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: <role> in course 123, <role> in department X, <role> in degree program Y, occupant of building Z, …

– What processes should determine entitlements for each affiliation?

• How should affiliations be structured?

4 June 2003 CAMP 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”, …

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

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

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

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

4 June 2003 CAMP 22

BoF Bait??