Deciding Who’s on First?: Establishing the Identity Management Leadership Group

Deciding Who’s on First?: Establishing the Identity Management Leadership Group October 11, 2006 EDUCAUSE @ Dallas

Who* from the University of Wisconsin-Madison • Carrie Regenstein (now at Carnegie Mellon) • Joanne Berg (Enrollment) • Ron Kraemer (Deputy CIO) • *First Base • Abbott and Costello

Presentation Overview • Introduction and problem statement (Carrie) • UW-Madison’s work toward a solution and our lessons learned (Joanne) • Suggested guiding principles for others and UW-Madison’s next steps (Ron)

What* is Identity Management? • Identity Management allows us to tell if individuals are who they say they are. • *Second base

And Why* Do We Care? • Identity management permits data custodians and service providers to control access to information and/or services, according to an individual’s identity, roles and responsibilities. • It permits us to confirm that individuals are affiliated with the University and what entitlements that affiliation allows. • New technology is enabling us to build an integrated network of relationships between data custodians and service providers on campus. • *Left field

Sounds great! Why are you concerned? • Because* up until 2004, ID mgmt was a fairly ad hoc process, due to an absence of policy and/or an absence of standards for how decisions were made. • As new systems, applications and services were introduced across campus, procedures to coordinate and manage access also needed to be developed. • * Centerfield

What changed in 2004? • Before then, ID management issues were seen as tactical technology questions rather than enterprise-wide policy issues. • The question was: “Who is responsible for making these decisions?” • The default answer was: “I don’t know.”* • *Third base

What were the drivers in 2004? • Driver #1: Identity Management • “From Cradle to Endowment” (Bob Kvavik) • In addition to students, staff, faculty: applicants, parents, alumni, retirees, donors, visitors, guests, etc. • Managed case by case in Special Authorization system

Driver #2: Access to Services • Needed to provide select services to extended institutional community, but lack of policy and contemporary technical architecture yielded “All or nothing” service entitlement decisions, based on credentials. • We also needed more effective and efficient management of services with varied risk and load tolerance, e.g., • A visiting professor needs access to the network and course management system. • UW Hospital Employees need access to Parking application. • UW Connections Students get almost the same services as UW-Madison students. • Students want parents to have access to their tuition statement and/or their student record • The Registrar wants alumni to authenticate to order official transcripts

Driver #3: New technology facilitated access to services • http://www.my.wisc.edu — Award-winning enterprise portal: • Opportunity: “One stop shopping” concept – enrollment services, earning statements, library services, grading, calendar, email, etc. • Challenge: Affiliation and service lifecycle issues, e.g., Undergraduate Applicants could access financial aid and admission status in the enterprise portal, but they did not get any other services until they enrolled and changed status to Student.

What would a new strategy require technologically? • The new (automated!) technology needed to be able to: • Define, represent, and manage lifecycle of affiliations • Support ad-hoc as well as institutional affiliations • Support delegated administration • Separate AuthN/Z processes • Determine who gets what • Offer services selectively • DoIT (Division of Info Tech) started to develop a role-based authorization system that could fulfill these requirements (Populations, Affiliations & Service Entitlements: PASE) • See: Grouper & Signet: http://www.internet2/edu

So, should technologists make these policy decisions? No! • We needed to deal with organizational, cultural, and technical issues: • Who decides priorities? • Who decides policies? • “Who ya gonna trust?” • We therefore needed to: • Use a strategic rather than “band aid” approach • Clarify leadership and decision-making roles • Engage stakeholders, work collaboratively • Establish appropriate governance

How did we get leaders’ attention? • We hailed the benefits of “access to data” • It was the sound of “one hand clapping” • So we clarified role definitions: • Technology (our job) • Services (special requests to us) • Policy (which technologists made de facto since the “Business is in the Bits”) • People were interested, but unmotivated to change. • So we focused on what we do best: technology • Staff were not allowed to provide ‘one-off’ (policy-laden) services, which gave them time to develop a more robust middleware infrastructure…. Which gave us a worthy technology to present.

We were in New Territory! • So we also needed • Patience • It took over 2 years of exploration, work, and collaboration to receive the memo of invitation to the university’s governance group • The right partner(s) are primary data stewards • Director of Human Resources • The University’s Vice Provost for Enrollment Management

My role • Enrollment Management and Registrar • Co-chair, Identity Management Leadership Group

Why I care about identity management • Ensuring privacy of student data • It is at the core of everything we do (or think about doing…) • Getting the right people to the right information • Getting the job done (focus on university core mission: student service, student success, academics, research) • A good IdM system makes for more efficient business processing

What is different about IMLG at UW-Madison • Who is on the team & who comes to the meetings • We all agree…it’s not just about the technology, it’s also about the people • And about the business process and the policy… • How we are structured • Project management model (charter sub-teams) • Developers • CIO

What works at UW-Madison • Behind the scenes work done before the meetings – meeting time is mostly meaningful • A healthy respect for the academic culture • Blurring the lines between technologists and policy makers – finding a common language • Sub-teams from across campus • Developers know they are not alone • We are flexible and patient (usually)

What doesn’t work at UW-Madison • Administration doesn’t completely understand the complications of identity management infrastructure • Push for a “one-card” ID system consumes high-level discussions about IdM • Complicated IT architecture complicates discussions about IdM • Never enough time

Suggested Guiding Principles • IdM as a value proposition • Strategic Project management • “Geek speak” and the non-geek • Education and re-education • Transparency, simplicity, flexibility

Next at UW-Madison - Projects • Meet the criteria to join “InCommon” • Establish one “identity” database • Implement Grouper/Signet • Continue implementation of our “role-based” authorization IdM solution • Build an “Operational Data Store” • Continue build-out of campus technical infrastructure

Next at UW-Madison - General • More education - better communication • Better provisioning of workflow and access management • Build the business case for identity and access management on campus • Implement a sustainable funding model • Sustain the momentum

Questions and Conversation

Deciding Who’s on First?: Establishing the Identity Management Leadership Group