Phase 2 Governance Board Recommendations

Populations and Data Sources

Enterprise Directory Population	Data Source
Current employees (regular, faculty, and temporary) & emeritus faculty at all three campuses	M-Pathways HEPROD database
Ann Arbor active students, including incoming students	M-Pathways HEPROD database
Flint active students, including incoming students	Banner student information system
Dearborn active students, including incoming students	Banner student information system
UM Online (UMOL) subscribers	ITCS UMOL database
Living alumni	DAC database
Other Sponsored Individuals	The ED will include a new "Sponsor System" for managing identities and access control for these individuals.

Sponsor System

A key deliverable of the Enterprise Directory Services project will be a Sponsor System, which will provide an easy to use and well documented process for units to create person entries, assign login IDs, and manage the identity lifecycle. The project will deliver two methods of interacting with the Sponsor System:

1. A Web-based user-interface for ad-hoc ID creation and lifecycle management
2. A programmatic method to integrate ID creation and lifecycle management with local systems

The project will also deliver documentation and guidelines for using the Sponsor System including:

1. Document the institutional processes for creating entries for students, employees and alumni sounits can avoid creating duplicate identities for these populations.
2. Document the institutional processes for maintaining directory entries beyond termination of employment, retirement, graduation, or death.
3. Guidelines for units on when to use the sponsor system, such as needing to issue a uniqname, or wanting to provision services based on directory roles.
4. Document minimum data standards for creating sponsored identities. (See recommendation below)
5. Document units' responsibilities in maintaining lifecycle of sponsored identities. (See recommendation below)
6. Document process for entries to be deactivated and reactivated.
7. Document rules for deactivation and purging.

Use cases

Units need a way to easily provide this access, and at the same times ensure a smooth transition from the "unofficial" affiliation to the "official" affiliation.

Units on campus also have a need to create identities and accounts for individuals who are not, and may never be students, staff, faculty, or alumni. Some specific examples include research collaborators, contractors, conference attendees, and other guests.

The duration and range of access needed for these individuals varies widely. For example:

• A three-day conference attendee who only needs a temporary login to the U-M wireless network.
• A school or college recruiter may have a long-term association, but may only need a U-M Friend Account to access School/College Web resources.
• A six-month contractor in a U-M unit who needs access equivalent to that of a regular U-M employee.

The Sponsor system must support the creation and management of different types of IDs to meet these varying needs.

Minimum Data for Sponsored University Affiliates

1. Required for all Sponsored University Affiliates
• Full Name
• Non-UM e-mail address
• Affiliation type or "Business reason" (this will be a predefined list such as Visitor, Library Patron, Contractor, Incoming Faculty, etc.)
• Sponsoring Department
• Start date of this affiliation
• End date of this affiliation
2. Additional required data to create a new UMID, or match to an existing UMID.

Existing functionality in the M-Pathways system provides a robust searching mechanism to match IDs and avoid the creation of duplicate IDs for the same person. The ED will use the existing rules and functionality for creating a UMID in the M-Pathways system, which requires one of the following combinations of data:

Combination One	Combination Two	Combination Three
First Name	First Name	First Name
Last Name	Last Name	Last Name
Social Security Nbr	Social Security Nbr
Date of Birth		Date of Birth
	Gender	Gender
	Address	Address

Expiration and Deactivation

The ED should provide a flexible mechanism for units to determine rules for expirations, and the level of notification that should occur before expiration or deactivation of services occurs. For example:

• ED provides the individual with 14 days notice that expiration date is approaching.
• ED provides sponsoring department 30 days notice before an entry expires, and gives the option of extending or shortening the affiliation.
• Allow a grace period of seven days for full service to remain active for central services. (Departments decide their own policies for deactivation of services.)

Roles

The Enterprise Directory Services project will create a small set of "institutional" roles to describe our populations in very broad terms. Individual schools, colleges, and units may use the institutional roles to grant access to services, or they may wish to create their own "departmental" roles with additional criteria for determining the population.

The following guiding principles were developed to determine when a role is considered an institutional role versus a departmental role.

Institutional Roles	Departmental Roles
Meet the needs of many units, particularly those that provide campus-wide services	Meet a specific unit's or application's need
Are created and maintained centrally	Are created and maintained by a specific unit
Have published criteria that do not change without significant notice to campus	May have published criteria, but are within the unit's right to change
Describe populations that can be derived from institutional data, including start and end dates, and including sponsored affiliates	May be derived from a combination of institutional and local data.
Are defined in order to support centrally provided services, such as ITCS BCP services, network access (wired and wireless) Mcard.	Are used to manage access to local systems and local exceptions.

Institutional Roles and Attributes

The chart below describes the proposed set of Institutional roles, and also lists some of the more granular attributes that will be available for units to define ad hoc roles. For example, there will be an institutional role for all active students on the Ann Arbor campus. The School of Music may wish to define a departmental role that contains only the subset of students who are active in a School of Music academic group.

This list represents an initial set of institution roles for the Enterprise Directory. Prior to the initial rollout of the Enterprise Directory, the Governance Board will establish a process for evaluating and adding new institutional roles.

The list of additional attributes below is intended to show the most common attributes that would be used to define a role that is a subset of the institutional role. Nearly any attributes in the directory could be used. See "Person Attributes in ED" for a proposed list of attributes.

Institutional Roles	Definition	Additional attributes needed to create sub-groupings
All Students Ann Arbor Students Dearborn Students Flint Students	Continuing and incoming students regardless of enrollment; includes detached study.	Academic Group (School/College) Department Academic Level Program Begin Date
All Enrolled Students Ann Arbor Enrolled Students Dearborn Enrolled Students Flint Enrolled Students	Enrolled in at least one credit hour for "current" term. Use next term information during gap between terms.	Academic Group (School/College) Department Academic Level Program Begin Date Class/section enrollment Meeting Pattern (for Law wireless network rule) Term of enrollment
All Alumni Ann Arbor Alumni Dearborn Alumni Flint Alumni	Any person who has completed at least one semester.	School/College Department Class
All Faculty Ann Arbor Faculty Dearborn Faculty Flint Faculty	Defined as academic, instructional, and research appointments. See below.	VP Area Org Group Appointing Department Admin. Department Empl Status Tenure Status Job Family (bargained-for vs. non) Emeritus
All Regular Staff Ann Arbor Regular Staff Dearborn Regular Staff Flint Regular Staff	Current appointment in status Active, Suspended, Short-work break, Leave, Paid Leave	VP Area Org Group Appointing Department Admin. Department Empl Status Job Family (bargained-for vs. non)
All Temporary Staff Ann Arbor Temporary Staff Dearborn Temporary Staff Flint Temporary Staff	Current appointment in status Active, Suspended, Short-work break, Leave, Paid Leave	VP Area Org Group Appointing Department Empl Status Job Family (bargained-for vs. non) Last Pay Date
All Retirees Ann Arbor Retirees Dearborn Retirees Flint Retirees	Retired (PMOD=TRT), regardless of other appoints that may still be active.	VP Area Org Group Appointing Department Admin. Department Empl Status Tenure Status Job Family (bargained-for vs. non) Retired Faculty Designation
Sponsored Affiliate	Person has at least one department who is actively sponsoring them.	Sponsoring Department Start Date End Date Sponsorship Reason (e.g. Visiting Researcher, Contractor, Conference Attendee, etc...)

Definition of Faculty

The system will use Job Family data in the M-Pathways HRMS system to maintain the institutional Faculty role. Individual units will have the flexibility to define local access rules using more granular definitions.

Elevated System Access

The process for granting elevated access to the Sponsor and Role Management system should be modeled after processes in place today for granting access to the M-Pathways system, and should include:

• Required Access and Compliance training for all individuals who will have elevated access to Enterprise Directory data, even if that access is for view-only purposes.
• Specific additional training based on the level of access. For example, there could be separate training and access requirements for users of the Sponsor System versus the Roles Management System.
• Security roles in the directory itself that can be monitored, so that individuals who leave the University or move from one department to another can have their access removed or adjusted
• in a timely fashion.
• Identification of a departmental contact, for example, a unitŐs IT Security Coordinator, who will be responsible for assuring that connected departmental systems are being secured to the same level as the source systems, and that only authorized and trained individuals have access to these departmental systems.
• Involvement from Data Stewards or their delegates in defining training guidelines and content, and criteria for granting system access.

General Visibility of Person Attributes

• Public searches are those performed by any un-authenticated user of the white pages.
• Internal searches are those performed by an authenticated user of the white pages with an active role in the directory. Further clarification of what is considered an internal search will be provide in the next phase of the project as we examine the technical capabilities and constraints of the system

Employee Titles

1. Individual employees will not be able to hide or remove the HRMS-supplied title as they can today. This recommendation is guided by the existing practice regarding the printed staff directory.
2. Many users of the white pages application would like to have an editable attribute where they can provide a more specific or informal job title that varies from the one captured in the HRMS system. Allowing users to edit the otherwise official "title" attribute confuses authoritative data with user-supplied data. Rather than allowing users to modify the title attribute, we will instead provide an optional, user-modifiable "Description" attribute where a person can maintain a more specific or informal title.

Addresses and Phones

Comments:

1. The work address stored in HEPROD for employees is a campus mailing address, which may or may not be the specific location of a person's office. This attribute should be clearly labeled as Campus Mailing Address.
2. Campus Mailing addresses are not routinely inactivated when an employee terminates. The ED project proposal should include the effort to build an automated address inactivation process in HEPROD.
3. If a reliable source of "location" data were available, that information could be useful for access control/provisioning, and could be made available in the future in separate directory attributes.
4. Individual employees will not be able to hide or remove the Campus Mailing Address and Phone as they can today. This recommendation is guided by the existing practice regarding the printed staff directory.
• Except for extraordinary cases, such as stalking or witness protection, employees do not have the option to hide this information from the printed staff directory. Procedures are in place to account for those situations.
• Employees and departments do have the option of listing a departmental address and/or phone instead of the specific office location and direct phone line.
5. Many users of the white pages application would like to have an editable attribute where they can supply location information. Allowing users to edit the Campus Mailing address confuses authoritative data with user-supplied data. Rather than allowing users to modify the campus mailing address, we will instead provide an optional, user-modifiable "location" attribute where a person can maintain a location address.
6. DAC addresses are currently not fed to UMOD. We are assuming that they will not be fed to the ED until a new Alumni Directory application is built.
7. Current home address and phone are fed from multiple sources. The proposed precedence is to take the most recent address change from any source, except when you have a student that is active on more than one campus. In that case, the campus at which they are currently enrolled would take precedence. This option will depend upon the ability for all three campuses to send regular updates to the directory when students are no longer enrolled, or no longer active.

Comments and Questions

ED.Phase2.GB.Members@umich.edu

Information Technology Central Services at the University of Michigan

ITCS Home  |  Contact ITCS  |  U-M IT Resources  |  Wolverine Access  |  University of Michigan   January 15, 2008