University of Michigan MCommunity Project

1. University of Michigan MCommunity Project Liz Salley (salley@umich.edu) Product Manager, Michigan Administrative Information Services Luke Tracy (ltracy@umich.edu) MCommunity Co-Technical Lead, Information Technology Central Services http://www.itcs.umich.edu/mcommunity/

2. Project Overview • Who’s in, who’s out. MCommunity will allow the University to know who is and is not a member of the U-M community so that central University offices, departments, schools, colleges, and campuses can grant and remove access to online resources as needed and appropriate. • Managed data for managed access. It will provide identity management, roles management, data sharing and reconciliation, and directory services for U-M. It will bring together data from multiple institutional sources and will organize, present, and secure the data in a way that is particularly well suited to managing access to University resources. • A collaborative effort. Planning for, and development of, MCommunity is a collaborative effort across U-M IT units and across the many units that will use the new system.

3. Project Overview • One-stop directory shop. MCommunity will provide units and end users with a "one-stop directory shop" for provisioning of services, access control, and directory-enabled applications. • Robust tools. It will provide a robust set of tools that include/enable: • Identity and life-cycle management • Real-time provisioning of central IT resources • Real-time provisioning of local IT resources • Clearly defined and documented programming interfaces • Auditing system • Integrated workflow

4. Current Legacy Environment • For limited purposes. Directory Services purposed for white pages ande-mail delivery. • Weekly updates. Directory Services updated from Systems of Record weekly. • Home-grown ID management. Home-grown identity management based on NetID/LoginID management. • Data not purposed for provisioning. Institutional data sources not purposed for IT provisioning. • Central provisioning home-grown. Home-grown provisioning system for central IT services.

5. Problem Statements • Multiple data sources. Most units need to go to multiple data sources to obtain information they need; there is a lack of a common data management strategy. • Slow updates. Currently, data feeds do not arrive quickly enough to fully automate access provisioning or de-provisioning campus-wide. • Time-consuming to get access. Going through existing “official” channels to provision access for members of the extended University community, including guests, faculty with very short appointments, volunteers, etc., is very time-consuming and unrealistic. • Manual processes. Many units still use manual processes to create identities or allocate resources.

6. Problem Statements • Inconsistent data, duplicated effort. Storing user information locally can create data inconsistencies and, in many cases, causes duplication of effort. Many departments keep their own copies of data that are less current or accurate than authoritative sources. • Difficult to use. Existing authoritative data sources are difficult to use, and it is difficult to gain access to them. • Local control wanted. Units demand local control of access to IT services. • Consolidation needed. Institutional sources of identity data need to be consolidated into a central identity management system. • Better life cycle management needed. Consistent and predictable life cycle management practices are needed.

7. Data & Governance: Beginnings • Data policies in place. U-M has long-standing policies and a structure for institutional data stewardship and management.http://www.mais.umich.edu/access/policies.html • Unique ID in place. Existing IdM systems are already using a single, institutional Net ID (U-M "uniqname") and non-social security number ID (UMID). One person = one uniqname = one UMID • Single ERP system in place. Student Administration (SA) and HRMS systems of record have already been transitioned from many separate mainframe applications to a single, integrated PeopleSoft ERP system.

8. Data & Governance: Convening a Team • Early input from stakeholders. MCommunity Governance Board convened before project was funded. Membership includes: • Institutional data managers for student, employee, and alumni data • IT directors and managers from representative schools, colleges, health system, and libraries • IdM project leads from central IT units (Luke and Liz) • Pre-implementation phase. Two-hour meetings, twice per month, for 8 months. Established high-level scope and vision; assisted enormously in building our business case and estimating the project timeline and costs. • Implementation phase. Two-hour meetings, once or twice per month, for 16 months. Continued to guide high-level scope and vision, as well as make detailed implementation decisions.

9. Data & Governance: Key Outcomes • Strong vs. weak identities • Vocabulary: How do we talk to campus about what this means? • Minimum data standards • Identity lifecycle • Real-life business cases

10. Data and Governance: Key Outcomes • Authority and accountability • How do we enforce standards in a highly decentralized environment? • System enforcement vs. guidelines and best practices • Decentralized authority and accountability to ensure guidelines and best practices are followed • Resources for IT directors • See “MCommunity Sponsoring Authority Policies and Agreement”http://www.itcs.umich.edu/itcsdocs/r1460/

11. MCommunity Project Architecture

12. MCommunity Project Architecture • Live data feed from Human Resources and main campus Student System of Record. • Nightly updates from remote campus Student Systems of Record. • Nightly updates from Development/Alumni System of Record. • New Sponsor System for creating and managing identities for sponsored affiliates, people who are affiliated with the University but who do not appear in any of the official University Systems of Record. • Sponsored affiliates include, for example, conference attendees, contractors, incoming faculty who need access to U-M resources before the hiring process is complete, and others. • Support for both strong and weak identities. • All person data from above systems fed into a secure person registry.

13. MCommunity Project Architecture • Inside the person registry. Real-time identity matching and reconciliation, institutional data precedence rules, data normalization, regulatory privacy policy, and identity lifecycle processing occurs in the person registry. • Exception handling. Workflow system is utilized for exception handling. • In real time. Distilled identities are populated and maintained in the directory in real-time. • In the directory. Institutional Roles, User Groups, Departmental Roles, and departmental attributes exist in the directory. • One stop for IT provisioning. Directory functions as the one-stop directory shop for IT provisioning.

14. MCommunity Project Architecture • Real-time bi-directional provisioning tools facilitate central and departmental IT provisioning. • Full LDAP access provided through a replica of the directory to facilitate business-rule verification prior to committal to directory. • All components of MCommunity are instrumented for central auditing and logging, enabling event correlation and incident response.

15. Reflections on Progress So Far • Implications of our vendor solution: • Up until now, we have mostly used open source and home-grown products to meet the extensive customization needs of the diverse U-M community. • Customizing a vendor solution has brought with it staffing and cultural issues that we are addressing and learning from. • Expectations of magic • Scope creep • Introduction of project management methodology • Enterprise vs. commodity service • Systems programmers becoming enterprise developers