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

Common Solutions Group The Question at Hand… How do [we] verify a person is who they say they are…at first and over time? More to the point…who they assert they are in various contexts… January 5, 2006 Common 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. January 5, 2006 Common 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? This matters since it forms the basis for most school ID bootstrapping procedures. January 5, 2006 Common 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 requirements Standardizes bootstrapping documentation Establishes common practice for renewal Federalizes authority and penalties …and the good old IRS January 5, 2006 Common 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) January 5, 2006 Common Solutions Group Winter Meeting @ Duke

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

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

Examples of University IdM Practice Stanford University New York University University of Chicago Rather than giving the ECAR summary, we’ll tell you a bit about our places… January 5, 2006 Common 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 January 5, 2006 Common Solutions Group Winter Meeting @ Duke

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

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

Common Solutions Group 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. January 5, 2006 Common Solutions Group Winter Meeting @ Duke

Common Solutions Group 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 January 5, 2006 Common Solutions Group Winter Meeting @ Duke

Common Solutions Group 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 January 5, 2006 Common Solutions Group Winter Meeting @ Duke

Common Solutions Group 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? January 5, 2006 Common Solutions Group Winter Meeting @ Duke

Common Solutions Group 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) January 5, 2006 Common Solutions Group Winter Meeting @ Duke

Common Solutions Group 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”. January 5, 2006 Common Solutions Group Winter Meeting @ Duke

Common Solutions Group 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 January 5, 2006 Common Solutions Group Winter Meeting @ Duke

Common Solutions Group 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? January 5, 2006 Common 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 January 5, 2006 Common Solutions Group Winter Meeting @ Duke

Common Solutions Group 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 January 5, 2006 Common 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. January 5, 2006 Common Solutions Group Winter Meeting @ Duke

Common Solutions Group 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 January 5, 2006 Common 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 January 5, 2006 Common Solutions Group Winter Meeting @ Duke

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

Common Solutions Group 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 One size IdM and AuthN/Z practice does not fit all Data consistency (multiple entries for a person) More online, same practices, fewer people to intermediate, more online transactions Control of digital assertions of institutional identity January 5, 2006 Common 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 January 5, 2006 Common Solutions Group Winter Meeting @ Duke