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/
1
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.
2
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
3
Current Legacy Environment
•
•
•
•
•
For limited purposes. Directory Services purposed for white pages and
e-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.
4
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.
5
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.
6
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.
7
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.
8
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
9
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/
10
MCommunity Project Architecture
11
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.
12
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.
13
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.
14
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
15