August 14, 2007 Chapter 2. Identity Management Requirements Identity Management. Table of Contents Definitions Bona fide identity. Digital identity.

Transcription

1 August 14, 2007 Chapter 2. Identity Management Requirements Identity Management. A comprehensive set of tools and processes for creating and managing digital identities for all entities that are affiliated in some capacity with U-M and that need access to IT resources. Table of Contents Definitions... 1 What Is Identity Management?... 2 How Will It Be Used?... 2 Business Process Model... 3 Dependencies... 3 Business Requirements... 3 Appendix 2-A: Populations and Data Sources... 4 Appendix 2-B: Search-Match and Minimum Data Requirements... 4 Appendix 2-C: Identity Lifecycle Use-Case Analysis... 4 Definitions Bona fide identity. An identity supplied to MCommunity that was generated in an institutional source system, such as the Human Resources or Information system, using established institutional identity creation practices and therefore possessing an inherent high level of assurance and validity. Digital identity. The electronic representation of a real-world entity. The term is usually taken to mean the online equivalent of an individual human being, which participates in electronic transactions on behalf of the person in question. However, a broader definition

2 also assigns digital identities to organizations, companies, and even individual electronic devices. 1 Strong identity. An identity in MCommunity that contains adequate identity data to confidently match against identities in other systems. Weak identity. An identity in MCommunity that lacks adequate identity data to confidently match against identities in other systems. What Is Identity Management? Identity Management is a comprehensive set of tools and processes for creating and managing digital identities for all entities that are affiliated in some capacity with U-M and that need access to IT resources. Identity Management also includes capabilities to manage non-person entries in the Directory. 2 Identity Management is not a monolithic application, but rather a series of tasks performed by multiple software components and technologies. MCommunity Identity Management is not a provisioning system; its tools manage identity data but do not assign resources. Provisioning tools and logic outside of Identity Management will be used to assign resources. Resource owners will be able to define and implement criteria, based on identity data, that will be used to grant and revoke access to resources. How Will It Be Used? Identity Management will be used to: Implement a comprehensive identity lifecycle management process that Creates identities in the Registry. Assigns LoginIDs (also known as uniqnames). Populates IDs in the Directory. Manages data changes in the Registry and Directory. Depopulates IDs from the Registry and Directory. Facilitate the creation and management of non-person identities for the purpose of providing access to MCommunity systems and resources. Utilize Workflow to automate identity creation and management processes. 1 From 2 Non-person entries would include, for example, system identifiers such as root, bin, oracle, and others, which are specific to particular environments and ought to be reserved, but which need no other central resources. Non-person entries also include keytabs, special login identities, pt instances, and other resources used for automated processes. page 2

3 Business Process Model Dependencies MCommunity Identity Management is dependent on: Authoritative sources of identity data for creating and managing bona fide identities. These include, the Dearborn and Flint Banner systems, and the Development Constituent (DAC) system. The Sponsor System to create and manage non-bona fide identities The Identity Vault to store identity data and on other processes to manage the population and management of the identity data in the Directory; assign and manage uniqnames, UIDNumbers, and GIDNumbers; and to manage memberships in Institutional Roles. 3 Business Requirements These business requirements focus on meeting the needs of unit IT staff, unit administrative staff, and end users. For End Users (Interactive Access) 1. Uniqnames will be either assigned or self-chosen for an identity, ensuring uniqueness and naming standards. 2. Via Workflow, users with assigned uniqnames will be notified of their assigned LoginID and UMICH Kerberos password. For System Administrators (Programmatic Access) 3. Identity Management will create and manage Kerberos Principals for identities in MCommunity. 4. Any authoritative source will be able to create a new identity. 5. Identities will be assigned a system-generated unique identifier. 6. A process responsible for performing the consolidation of identity data from multiple sources and enforcing the data precedence rules defined by the Governance Board will be in place.) NOTE: The Governance Board has yet to define precedence of data from multiple sources, which will be present in the Directory. 7. Identity Management will populate identities into the Directory as specified by criteria set forth by the Governance Board. 3 See: University of Michigan, Enterprise Directory Services Phase 2 Governance Board Recommendations, Ann Arbor, Michigan, July This is included in Chapter 1 and is on the web. page 3

4 8. A process will be responsible for assigning unique identifiers (for example, UIDNumbers and GIDNumbers). 9. Identity Management will provide the ability to manage non-person identities in the Directory, which could include system related identities, or other types of objects (rooms, hardware, networks.) NOTE: This needs further definition to determine true needs and business relevance for MCommunity. Appendix 2-A: Populations and Data Sources Enterprise Directory Population Current employees & 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 U-M Online (UMOL) subscribers Living alumni Other sponsored individuals Data Source M-Pathways database M-Pathways database Banner student information system Banner student information system ITCS UMOL database DAC database MCommunity will include a Sponsor System for managing identities for these individuals. Appendix 2-B: Search-Match and Minimum Data Requirements The minimum data required to create a UMID or match to an existing UMID is any one of the following three data combinations: Combination One Combination Two Combination Three First Name First Name First Name Last Name Last Name Last Name Social Security Number Social Security Number Date of Birth Date of Birth Gender Gender Address Address Additional data could include uniqname, UMID (if known), external system id, former names, and nicknames. Appendix 2-C: Identity Lifecycle Use-Case Analysis This use case provides an example of the many events that might occur during the lifecycle of a particular identity in the MCommunity system. Use Case Summary Li Ping, who lives in China, applies to the University of Michigan Engineering School. She matriculates, chooses liping as her uniqname, arrives in Ann Arbor two weeks before school starts, goes through orientation, and moves into a residence hall at the beginning of the term. During her first term, she applies for a job and is hired as a temporary employee. After her first year at U-M, she moves from the residence hall to an apartment. She decides to change her preferred name to Linda Ping. In her last semester of school, Linda marries and requests that her uniqname be changed to lsmith to match her new last name (Smith). The couple moves into a house. Linda s spouse uses her account (and, therefore, her identity) to send hate mail to the White House. The User Advocate steps in and temporarily disables the account. A divorce happens shortly afterwards. Linda changes her last name back to Ping and requests that her uniqname be changed back to liping. Linda graduates and moves to Houston. She loses access to her IFS file space when she is no longer a student. page 4

5 Assumptions is the authoritative data source for events such as matriculation and registration. Detailed Use Case Events Event Process Attributes in the Directory Li Ping applies to U-M and is admitted. She matriculates. Necessary information is entered in, and UMID is created or updated. contains l bio-demo and address data. Possible problem: Duplicate UMID exists and must be resolved. Initial student record (see schema) is sent to the Directory. User self registers uniqname and can go to cosign-enabled websites, register for classes, get housing, and so on. BCP is set up automatically. *Check with Novell about Identity/uniqname selfregistration process None Personal Data Academic Data Uniqname (liping) Password BCP Registry entry Information hidden in white pages Private flag on (will be brought to/confirmed with the Gov. Board) Institutional Roles None AA Authoritative Data Source She attends orientation and registers for classes. Gets M-card Enrollment data sent to Personal Data Academic Data Enrollment Data Uniqname Password BCP Registry entry AA Arrives on campus and starts classes. Becomes temp employee. Privacy flag is on. A week before classes start (?), the privacy flag is taken off, and actual FERPA starts? Job data added to FERPA flag change in BCP data and Directory entry Directory entry affiliation addition FERPA protection changes AA AA AA Temp Moves from res. hall to apartment. Takes summer classes in Dearborn. Changes preferred name. Address changes in Enrolls in Dearborn classes needs access to resources in Dearborn Name updated in Address updated in Dearborn student data Preferred name added to AA AA Dbn Dbn Enrolled AA Dearborn page 5

6 Event Process Attributes in the Directory Marries and requests uniqname change. Moves to the house. Husband abuses her login privileges. Campus ID (uniqname) changed in Any effect on job data? No Address change in User advocate finds out New uniqname - lsmith Address updated in Account is disabled How is account restored- by divorce? Institutional Roles AA AA AA Divorces. Any effect on job data? No AA Requests uniqname change. Graduates. Job ends. uniqname updated in Update to academic data Update to job data Uniqname changes to lping data removed data removed AA Authoritative Data Source Moves to Houston. Updates address with alumni office Address updated in See the MCommunity website for additional scenarios. page 6