Appendix 10: Identity Lifecycle Management

  1. Examples of current challenges that can be resolved with an effective identity management program
  2. Identity Management Implementation Three-Year Action Plan as Provided by OIT

Appendix 10A – Challenges Resolved with Effective Identity Management

  1. Multiple systems independently manage identities

The University has multiple systems that manage identity. Microsoft Active Directory provides access to resources on the network. Another system provides access to the wireless network, while yet other applications (e.g., MyUNLV) manage identities within the individual application.

  1. Identity information is stored in multiple places

Storing identity information in multiple places means that each time the university buys or builds a new IT system technologists must spend considerable time determining how identities for that system will be handled. When an application is built it must include a way to control access to data. When an application is purchased an internal store must be populated either manually or by drawing data from an authoritative source (e.g., the student information system - MyUNLV, the human resources management system - HRMS). The internal store must also be maintained as people enter and leave the system.

  1. Management of multiple identities

Individuals at UNLV have multiple identities, sometimes even within the same system. Multiple identities create several challenges. For example, if a student needs to reach the instructor of a class, knowing the instructor’s phone number and email address would be convenient. If the instructor’s identity in MyUNLV is not tied to a record in HRMS, the contact information must be entered and maintained in both systems, creating additional work and the possibility for inconsistencies between the systems. This situation is even more complicated when we attempt to build an application like a Web portal that gives people access to multiple systems (e.g., MyUNLV, HRMS, WebCampus, e-mail). The lack of a common unique identifier in MyUNLV and HRMS makes it difficult to match a faculty member in HRMS to an instructor in MyUNLV. Thus, it is very difficult to give faculty access to information that is restricted to the instructor of a particular course. When individuals leave the university, their access to multiple systems is revoked one system at a time. An identity management system would ensure that the individuals are removed from all systems simultaneously.

  1. Separate identities create a variety of security risks

Separate identities can also create the opportunity for harm. Creating a single identity makes it easier to audit and prevent inappropriate actions. For example, an identity management system would set up a single identity that included information about the multiple roles for a UNLV employee enrolled in a class (i.e., employee and student). The employee, call her “Jen Doe,” requires access to data in the student information system to do her work. Jen would be able to edit information in accordance with her job responsibilities but be prevented from making changes in the course for which she is enrolled. In the absence of a single identity, safeguards against this kind of activity must rely on people who know that the “Jen Doe” taking the class is the same as the “Jennifer Doe” who edits information in MyUNLV.

  1. Systems lack the automation to keep data updated and consistent across systems

It should be possible to enter data only once. When someone joins the faculty or is admitted as a student, an authoritative record should be created in MyUNLV or HRMS. The information from one of these systems should populate other systems automatically. The other systems should regard MyUNLV and HRMS as “sources of truth” and not alter the information. Any changes should be made only once in the authoritative system and propagated to other systems as needed.

Appendix 10B – Identity Management Implementation Three-Year Action Plan

Phase 1: Complete the Initial Implementation

  1. Install and configure UNLV’s Identity Management, Access Management and Federated Identity Management suite.

The new software suite will be populated with core data about every UNLV employee and student. Each individual will have an ID and password. This is the basic foundation for the identity management system. This first set of core data will contain limited information and attributes about the individuals. The core data will be built out over time.

  1. Populate the system with the minimum attributes needed to establish a basic Shibboleth Federated Identity required to participate in the InCommon Federation.

The InCommon Federation is the U.S. education and research identity federation, providing a common framework for trusted shared management of access to online resources (more information available at:

InCommon grants several layers of trust based on the security and robustness of the home institution’s identity management systems. In July 2015 UNLV completed the most basic connection to support sharing/borrowing of library research materials through the HathiTrust (more information available at:

  1. Establish synched single ID (i.e., login) and password for multiple campus systems.

Users will have a single login and password for the following systems: Blackboard Learn, MyUNLV, email, Google Apps, iLeave, desktop login, and Virtual Private Network (VPN) services.  When a user changes his or her password it will be changed in all of the systems with no further action needed.

Phase 2: Provide Access to Multiple Campus Applications

  1. Add Secure Wireless to the group of applications that use the identity management system for authentication.
  2. Ensure access (i.e., logins and passwords) and authentication (e.g., role-based provisioning) for new enterprise applications and/or cloud services are compatible with the campus identity management system.

As new applications are considered for campus adoption, a review of how the access and authentication will be handled will be required. Whenever possible, the campus standards for access and authentication will be used and the identity management system will be the source for the required data. Exceptions will be granted as needed and non-standard authorization solutions will be integrated with the campus identity management system through purchased products or in-house integration development.

When necessary, new groups will be added to the identity management system to accommodate the access and authorization requirements for new applications.

  1. Add additional core data to the identity management system to allow for more fine-grained access to campus systems.

Bringing more data from the student information system into the identity management system will make it possible to increase the number of groups in the system based on attributes such as academic department or students in a particular course. The new groups can then be used to allow access to resources restricted to those groups (e.g., an academic department website used only by members of that academic department, course materials stored in a file management system for use by the members of a particular course).

  1. Implement account deprovisioning functionality within the identity management suite.

To help ensure the security of institutional data, it is imperative that access to university accounts be deactivated or deleted when a member of the campus community leaves. The identity management suite provides functionality that will assist with the deprovisioning of all accounts that are connected to the suite. As development of the application continues, it will also be possible to fine-tune the deprovisioning processes to accommodate changes in access when employees transfer positions (e.g., staff member moves from the Registrar’s Office to the Cashier’s Office) or take on new responsibilities (e.g., a faculty member is elected chair of an academic department for a three-year term).

Phase 3: Extend the Functionality

  1. Make available role-based authorization to support collaboration, application, and data access based on role/group identities for employees using data from iNtegrate 2.
  2. Expand the basic information needed for InCommon to include full eduPerson classification to support easier access to research, grants, and collaboration requiring higher levels of security.

The eduPerson classification schema includes widely used information about individuals in higher education environments to provide a common list of attributes and definitions to make secure access to systems across institutions easier. More information about the full eduPerson classification attributes can be found at:

  1. Develop strong links between data governance and identity management.

The identity management system is dependent on a strong data governance structure. The determination of who should have access to what data and what type of access they should have (e.g., read only, create, edit, and delete) is the responsibility of the campus Data Stewards. Procedures for determining what access is appropriate for a particular type of data or for a particular role on campus (e.g., faculty member, department chair, student) need to be developed as part of data management and reporting efforts included in Initiative #13. Only after the access and role decisions are made can the identity management system be used to provide appropriate authorization and differentiated access.