Enterprise Directory Services Phase 2 Governance Board Recommendations

Transcription

1 MAIS Information Technology Central Services and Michigan Administrative Information Services Enterprise Directory Services Phase 2 Governance Board Recommendations Populations and Data Sources The goal of the UM Enterprise Directory Services is to provide a consolidated view of all persons affiliated with the university, regardless of source. Basic identifying data will include a consistent view of a person s name, login id, and current affiliations. Additional, fine-grained information will be available to university units for purposes of provisioning access to university resources. The future Enterprise Directory will include the following populations: Enterprise Directory Population Current employees (regular, faculty, and temporary) & emeritus faculty at all three campuses Ann Arbor active students, including incoming students Flint active students, including incoming students Dearborn active students, including incoming students UM Online (UMOL) subscribers Living alumni Other Sponsored Individuals Data Source M-Pathways HEPROD database M-Pathways HEPROD database Banner student information system Banner student information system ITCS UMOL database DAC database The ED will include a new Sponsor System for managing identities and access control for these individuals. Sponsor System In today s U-M Online Directory (UMOD) several challenges arise due to the difficulties of keeping identities unique, and managing the lifecycle of the identity as persons come and go and change relationships with the University. Our institutional sources for student and employee data have minimum data standards that exceed the needs of the directory including data that can be used to revoke access, deactivate, and ultimately purge entries but not all of that data can be reasonably fed and processed with our current systems. The current processes for creating ad-hoc or sponsored entries for guests, contractors, and so on, do not provide a consistent method of collecting minimal data and managing the life-cycle of an identity. 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 Page 1 of 9 7/14/2006

2 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 so units 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 One of the most commonly stated cases for units to create identities and accounts for people is to provide early access to resources to incoming faculty, often months before they arrive on campus, and before the data is created in the HRMS system. 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 UM wireless network. A school or college recruiter may have a long-term association, but may only need a UM Friend Account to access School/College Web resources. A six-month contractor in a UM unit who needs access equivalent to that of a regular UM 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 There will need to be flexibility built into the ED so that entries can be created and used within minutes. Understanding that many of these entries are for short-term IDs, we do not want to make the data collection process more onerous than it needs to be, and we do not want to require certain visitors to provide more personal information than is truly needed. Therefore, we will need two sets of minimum data rules. University of Michigan Page 2

3 1. Required for all Sponsored University Affiliates Full Name Non-UM 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 Units will be required to take responsibility for the identities that they sponsor and must know what to expect if their sponsored entries are allowed to expire. Affiliations that are fed from institutional sources have end dates that can be derived from the source, and therefore will not be permitted to remain indefinitely in the ED. The Governance Board recommends that sponsored affiliations be reviewed at least three times per year. 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.) University of Michigan Page 3

4 Roles Directory roles describe a person s association with the University for the purpose of granting access to services. Directory roles, in themselves, do not necessarily describe what a person has access to; they only describe who the person is. Any given person may have multiple roles at the University at the same time. 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 Meet the needs of many units, particularly those that provide campus-wide services Are created and maintained centrally Have published criteria that do not change without significant notice to campus Describe populations that can be derived from institutional data, including start and end dates, and including sponsored affiliates Are defined in order to support centrally provided services, such as ITCS BCP services, network access (wired and wireless) Mcard. Departmental Roles Meet a specific unit s or application s need Are created and maintained by a specific unit May have published criteria, but are within the unit s right to change May be derived from a combination of institutional and local data. Are used to manage access to local systems and local exceptions. Institutional Roles and Attributes In the past, units have tried to use attributes in the UMOD to identify populations of student, faculty, or staff. The attributes in UMOD were designed in large part to be display-friendly, and are not necessarily suited to queries. In addition to the display-friendly attributes that will still be needed for a white pages application, the Enterprise Directory and its associated person registry, will contain attributes defined at a more granular level, making the data more suited to queries. The ED data will also be maintained on a real-time basis, making it more suitable for access control purposes. 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. University of Michigan Page 4

5 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 All Alumni Ann Arbor Alumni Dearborn Alumni Flint Alumni All Faculty Ann Arbor Faculty Dearborn Faculty Flint Faculty All Regular Staff Ann Arbor Regular Staff Dearborn Regular Staff Flint Regular Staff All Temporary Staff Ann Arbor Temporary Staff Dearborn Temporary Staff Flint Temporary Staff All Retirees Ann Arbor Retirees Dearborn Retirees Flint Retirees Enrolled in at least one credit hour for current term. Use next term information during gap between terms. Any person who has completed at least one semester. Defined as academic, instructional, and research appointments. See below. Current appointment in status Active, Suspended, Shortwork break, Leave, Paid Leave Current appointment in status Active, Suspended, Shortwork break, Leave, Paid Leave Retired (PMOD=TRT), regardless of other appoints that may still be active. Academic Group (School/College) Department Academic Level Program Begin Date Class/section enrollment Meeting Pattern (for Law wireless network rule) Term of enrollment School/College Department Class VP Area Org Group Appointing Department Admin. Department Empl Status Tenure Status Job Family (bargained-for vs. non) Emeritus VP Area Org Group Appointing Department Admin. Department Empl Status Job Family (bargained-for vs. non) VP Area Org Group Appointing Department Empl Status Job Family (bargained-for vs. non) Last Pay Date VP Area Org Group Appointing Department Admin. Department Empl Status Tenure Status Job Family (bargained-for vs. non) Retired Faculty Designation University of Michigan Page 5

6 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 definition of the Faculty role shall be guided by the university bylaws which state The term faculty shall include members of the teaching and research staff together with the executive officers, the directors of various teaching, research, and library units, research associates, curators, and persons with similar duties. 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 Sponsor and Roles Management systems described above are two key components of the Enterprise Directory Services solution. Users of these systems will have access to far more data than the average user of the Online Directory, including sensitive personal data elements and student-related data that are protected by FERPA. In order to meet the diverse needs of University units, access to these two systems must be granted to authorized individuals across all three campuses. Departmental systems that integrate with the ED through a programmatic API will also need to be granted the same 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. University of Michigan Page 6

7 General Visibility of Person Attributes The current U-M Online Directory displays more public information than our peer institutions. The board reexamined the amount of publicly available data in the UMOD, and recommends that more attributes be hidden by default, while allowing individuals the choice to make some of this information public. We recommend that some attributes always be hidden from public view, while remaining available to authorized unit administrators for provisioning and access control. The board also recommends that we enable more attributes to be visible to internal, authenticated users of the system than to external, non-authenticated users. 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 usersupplied 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. University of Michigan Page 7

8 Addresses and Phones Type of Address/Phone Current Employees Current Students Current Home Address (All students and employees) Feed to ED -Yes, unless Do Not Publish is selected in HEPROD -Yes, unless FERPA flag is set in HEPROD Default for public searches Hide Hide Default for internal Hide Hide searches Editable in the white pages No- must update at the source No- must update at the source Permanent Address (Ann Arbor Students only) Feed to ED n/a Yes, unless FERPA flag is set in HEPROD Default for public searches n/a Hide Default for internal n/a Hide searches Editable in the white pages n/a No- must update at the source Campus Mailing Address (All employees) Feed to ED -Yes -Remove when all employment terminated Default for public searches Show. Not allowed to be hidden. n/a Default for internal Show. Not allowed to be hidden. n/a searches Editable in the white pages No- must update at the source n/a n/a 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. University of Michigan Page 8

9 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 The Governance Board and Enterprise Directory project team invite members of the university community to comment on these recommendations by sending feedback to: ED.Phase2.GB.Members@umich.edu University of Michigan Page 9