CSG - Policy Discussion Identity Management Practice

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

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

3. 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. Common Solutions Group Winter Meeting @ Duke

4. "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? Common Solutions Group Winter Meeting @ Duke

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

6. 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) Common Solutions Group Winter Meeting @ Duke

7. I-9Form Common Solutions Group Winter Meeting @ Duke

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

9. 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 Common Solutions Group Winter Meeting @ Duke

10. Examples of University IdM Practice • Stanford University • New York University • University of Chicago Common Solutions Group Winter Meeting @ Duke

11. 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 Common Solutions Group Winter Meeting @ Duke

12. Common Solutions Group Winter Meeting @ Duke

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

14. Identifier Management at NYU Some NYU Background • 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. Common Solutions Group Winter Meeting @ Duke

15. Identifier Management at NYU Some NYU Background, con’t • 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 Common Solutions Group Winter Meeting @ Duke

16. Identifier Management at NYU Where do “identifiers” fit in? • • 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 Common Solutions Group Winter Meeting @ Duke

17. Identifier Management at NYU Our identifier “problem” • 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? Common Solutions Group Winter Meeting @ Duke

18. Identifier Management at NYU So what’s wrong with multiple identifiers? • 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) Common Solutions Group Winter Meeting @ Duke

19. Identifier Management at NYU Source of our problem 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”. Common Solutions Group Winter Meeting @ Duke

20. 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 Common Solutions Group Winter Meeting @ Duke

21. 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? Common Solutions Group Winter Meeting @ Duke

22. 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 Common Solutions Group Winter Meeting @ Duke

23. 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 Common Solutions Group Winter Meeting @ Duke

24. 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. Common Solutions Group Winter Meeting @ Duke

25. 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 Common Solutions Group Winter Meeting @ Duke

26. 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 Common Solutions Group Winter Meeting @ Duke

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

28. 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 Common Solutions Group Winter Meeting @ Duke

29. 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 Common Solutions Group Winter Meeting @ Duke