1. January 5, 2006Common Solutions Group Winter Meeting @ Duke CSG - Policy Discussion Identity Management Practice Bruce Vincent, Stanford Gary Chapman, NYU Tom Barton, University of Chicago

2. January 5, 2006Common Solutions Group Winter Meeting @ Duke The Question at Hand… How do [we] verify a person is who they say they are…at first and over time?

3. January 5, 2006Common Solutions Group Winter Meeting @ Duke IdM Practice - Scope of Discussion Reflecting on… Institutional processes and tools to assure that identity and identifiers are linked; initially and over time. How schools verify that a person is who they say they are…as long as it matters. What assurances are good enough.

4. January 5, 2006Common Solutions Group Winter Meeting @ Duke "Getting to know you, getting to know all about you". How does our government identify the domestic population? How do universities manage identity about populations/individuals? Other major institutions?

5. January 5, 2006Common Solutions Group Winter Meeting @ Duke Federal and State Government Birth certificates & other municipal credentials Federated ID - State Driver’s License REAL ID Act and State ID requirementsREAL ID Act –Standardizes bootstrapping documentation –Establishes common practice for renewal –Federalizes authority and penalties …and the good old IRS

6. January 5, 2006Common Solutions Group Winter Meeting @ Duke IdM Business Practice: U.S. Universities Varies between universities and their schools Varies between populations i.e. types of affiliation –Student (academic record) –Foreign student (…+ a U.S. Visa) –Staff (I-9 employment standards) –Faculty (varies by profession)

7. January 5, 2006Common Solutions Group Winter Meeting @ Duke I-9 Form

8. January 5, 2006Common Solutions Group Winter Meeting @ Duke IdM Business Practice: Other Institutions FFIEC (Clearinghouse for U.S. Financial Audit Requirements)FFIEC FDIC strongly recommending T-FAT-FA Credit bureaus

9. January 5, 2006Common Solutions Group Winter Meeting @ Duke Topic 2: How Well Does IT Practice Reflect Policy? Policy? Often IT has created business practice in the absence of policy. For employment, compliance to I-9 is consistent… Where required, more is done to bind identity to identifiers. Central IT is a partner in IdM processes

10. January 5, 2006Common Solutions Group Winter Meeting @ Duke Examples of University IdM Practice Stanford University New York University University of Chicago

11. January 5, 2006Common Solutions Group Winter Meeting @ Duke Stanford University IdM Processes Historically separate applications for Student and Faculty/Staff identity Merged populations in 1986 and created UnivID; stopped use of SSN broadly No reuse of identifiers…now 280,000 Recent audit response has password expiry for some roles

12. January 5, 2006Common Solutions Group Winter Meeting @ Duke

13. January 5, 2006Common Solutions Group Winter Meeting @ Duke Identifier Management at NYU Identifier Management At NYU Gary Chapman New York University January 5, 2006

14. Common Solutions Group Winter Meeting @ Duke Identifier Management at NYU 14 schools, colleges and divisions (including professional Schools -- Medicine, Dentistry, Business, Law) 16,000 employees (not including Medical Center) Students: Total: 50,917 Undergraduate: 19,401 Graduate and Professional: 18,990 Non-credit Programs: 12,526 Programs abroad in Florence, Prague, London, France, etc. Some NYU Background

15. January 5, 2006Common Solutions Group Winter Meeting @ Duke Identifier Management at NYU Person Registry: 1 million records with NetID and University ID assignments; 4 million records in total with University ID assignments; fed by systems of record. Now initiating formal Identity Management program: a series of projects to enhance Identity Management at the institution proof-of-concept phase, with implementation of Sun-One Identity Management Suite, policy and architecture development, staff education, client buy-in progressive phases of implementation: integration of centrally- managed systems with enterprise IdM system for provisioning, access management, privilege management Some NYU Background, con’t

16. January 5, 2006Common Solutions Group Winter Meeting @ Duke Identifier Management at NYU we authenticate people, so that we can authorize them for electronic capabilities based on our policies and their relationships to the institution. Identifiers are the “handles” we use to link people with their electronic capabilities. We keep track of these identifiers in any number of repositories (such as directories, password files, etc.) NYU has two main identifiers University ID (for tracking everybody) - e.g. N12345678 NetID (for electronic use) - e.g. gwc1 Where do “identifiers” fit in?

17. January 5, 2006Common Solutions Group Winter Meeting @ Duke Identifier Management at NYU Many people have been assigned multiple identifiers; people continue to be assigned multiple identifiers (at a low rate) We haven’t tracked down all the cases We haven’t yet tightened procedures so as to largely eliminate the problem continuing We find out about such discrepancies typically as a consequence of service-level problems (unhappy people!) we are devoting approximately 1 FTE to record clean-up if identifier assignment is at the core of our service provision, and this process is suspect… what risks, if any, do we incur? Our identifier “problem”

18. January 5, 2006Common Solutions Group Winter Meeting @ Duke Identifier Management at NYU Not bad… if intentional If unintentional, problems arise services are built on the assumption that a person has a single identifier within a domain aggregating systems will not present a unified view tracking or auditing utilization will not be accurate decisions based on the fact that a person is, e.g. both a student and an employee cannot be accurately made: our internal, electronic knowledge of our community will not be accurate (e.g. if you decide all students must opt-in to public directory) actions relating to the person may be misdirected (e.g. person has two e-mail addresses, but only uses one, and messages are sent to unused address) So what’s wrong with multiple identifiers?

19. January 5, 2006Common Solutions Group Winter Meeting @ Duke Identifier Management at NYU Identification is the initial step of creating new identity records and assigning identifiers to individuals. This is not done, for historical reasons, in a consistent and systematic way across the several ways that people are initially recorded in systems. E.g. compare student applicants (not on campus) with prospective employee. Checking to see if a person is already known to university systems is highly variable. So, we have different processes for employees, students, affiliates… yet we assign identifiers and then consider them equally valid and equally “good to go”. Source of our problem

20. January 5, 2006Common Solutions Group Winter Meeting @ Duke Identifier Management at NYU What to do? Understand entry points and identification processes now in effect Figure out goal state, e.g. reduced number of entry points? more consistent collection of more identity attributes? minimal creation of new identifier problems Develop an identification policy? (Hey, who’s in charge?) Implement new procedures, improved record checking, e.g. matching on more than SSN… Proactively clean-up current record discrepancies as possible Use re-identification opportunities (e.g. password forgotten, ID Card expired, etc.) to vet current data, collect more identity attributes for people

21. January 5, 2006Common Solutions Group Winter Meeting @ Duke Identity and Identifier Management at NYU What’s next? Identifiers Real-time identifier assignment; further integration with SoM Person Registry Data-cleaning improvements; integration with PASS; on-line ID Card application Directory Services Increased use by applications; augment with groups data; online public directory data available from UDW Groups & Roles Registry groups improvements; track Grouper initiative Account Provisioning Integration with Active Directory implementation Authentication Required, regular password changing; strengthen complexity; two factor authentication Authorization ID Card swipe authorization based on Registry groups/roles; track progress of Signet initiative Federated Identity Track progress of E-Authentication initiative, involvement soon? Planning Planning for an enterprise system: pilot Sun IdM Suite?

22. January 5, 2006Common Solutions Group Winter Meeting @ Duke IdM “Assurance Classes” Increasing level of assurance (LoA) required for some services –Data classification, other local policies –Response to HIPAA, SOX, GLB, eAuth –other Jones’ to keep up with Minimal LoA required for others –Low bar for loosely affiliateds, but also limited access Typical services lie somewhere in between Determines classes of people by high water mark LoA requirement

23. January 5, 2006Common Solutions Group Winter Meeting @ Duke Assuring Assurance A single one-size-fits-all authentication service won’t do Range of motion –Additional, stronger, authentication –Multiple authentication services –Multiple accounts or account instances –Accounts assorted into classes –Multiple identity providers Must avoid that last possibility! –Want ubiquitous adoption of netIDs

24. January 5, 2006Common Solutions Group Winter Meeting @ Duke UFlorida Password Policy Classes P1 : Entry. Vendors, guests, student applicants, HR applicants P2 : Low. Access to information only about yourself. P3 : Medium. Access to information about others. Provide data at unit level. P4 : High. Access to information at the institutional level P5 : Rigorous. Control institution systems.

25. January 5, 2006Common Solutions Group Winter Meeting @ Duke Password Policies Characteristics –Run-time: length, charset, lifetime, history –Password set/reset process Self-serve, phone, F2F –Account lockout?? Implementation within IdM system –Arrange for assurance obligations of each account to be inferred or tagged –Authentication service support for run-time characteristics?? –Notification processes

26. January 5, 2006Common Solutions Group Winter Meeting @ Duke Topic 3: Context Changing for Business Practice Regulatory controls increasing (e.g. CALEA, HIPAA, SOX) Risk Management context changing…more online of value Identity theft is a growing problem Individuals demanding more privacy More focus on role-based privileges

27. January 5, 2006Common Solutions Group Winter Meeting @ Duke cont. Context Changing for Business Practice Federations and digital trust relationships Support transient populations

28. January 5, 2006Common Solutions Group Winter Meeting @ Duke Where are the gaps? Three different concerns over IdM at our respective institutions: -Gary at NYU [done] -Tom at U of Chicago [done] -Bruce at Stanford

29. January 5, 2006Common Solutions Group Winter Meeting @ Duke Discussion and Questions …and a parting goal for all of us… “There’ll be no more talking to Who’s who are not!” Dr. Seuss