Central Person Registry Requirements. Identity and Access Management Central Person Registry Software Requirements Specification

Transcription

1 Identity and Access Management Central Person Registry Software Requirements Specification 22 September

2 ! "#$%&!'(!)'*+&*+,!!! "#$%&' (!!)!! *+&,-*.*#/-*$,' (!!)0! "1"-&2'$3&43*&5' (!!)(! +$#62&,-'$3&43*&5' 7!!)7! -&42"'/,+'/884&3*/-*$,"' 7! 0! 4&.&4&,#&+'+$#62&,-"' 9! (!.6,#-*$,/:'4&;6*4&2&,-"' <! ()!! <! ()0! ()(! ()7! 00! 7!,$,B.6,#-*$,/:'4&;6*4&2&,-"' 0A! 0A! C!.6-64&'4&;6*4&2&,-"' (D! A! /%%&,+*='!'6"&'#/"&':*"-' (!! 2

3 1 Scope 1.1 Identification The requirements presented in this document are for the Identity and Access Management's (IAM) Central Person Registry (CPR). This document is a living document and will be updated as future requirements are identified. Because this document contains requirements for multiple phases of the CPR, the last column in each requirement table identifies which phase of development the requirement is associated with. 1.2 System Overview The Central Person Registry is a single data store that combines and consolidates identity information from disparate systems. Currently most of Penn State s critical identity information is stored in multiple systems such as ISIS, IBIS, OHR, CIDR, ID Card System, LDAP (Lightweight Directory Access Protocol), and CACTUS. LDAP, the standardized directory infrastructure that supports Penn State s Online Directory Services, is the closest approximation to a central person registry at the University. However, LDAP is not complete and updates from other sources are not always consistent and timely. The new central person registry will combine identity data records from these disparate University systems. Integrity rules will be applied that would ensure the validity of the identity data resulting in a complete and up-to-date person record for each individual University member or affiliate. Systems of Record Database Web Services Service Providers Registration Authorities Central Person Registry Data Views Figure 1 - Central Person Registry The CPR has two main components: A database of user identity information. A set of web services that are used to interact with the registry. 3

4 1.3 Document Overview This document is composed of four sections: Scope Referenced Documents Requirements Appendices 1.4 Terms and Abbreviations Term Access and Security Representative Account CACTUS Captive Account CIDR Computerized Institutional Data CPR Data Steward Definition An individual, usually an administrator of a major University office (e.g., college or campus) or designee, who coordinates requests from administrators, faculty and staff within the unit. The means by which an individual establishes access to a specific University Computer and Network Resource. The term "Account" also is often used to apply to the file space or services reserved for that individual on the specific resource Central Accounts Coordination Tracking of User Services. This is the database for Access Accounts. An Account where the user can access a restricted list of application programs only and has, at most, restricted network access. Central ID Repository. CIDR provides information on various ID functions throughout Penn State, including password and Social Security Number (SSN) changes. CIDR contains biographical information used by various systems across the University, including the University s PSU ID and SSNs. Institutional Data that is captured, stored, maintained, accessed or used by a computer system. Central Person Registry. An administrator or designee who is responsible for Computerized Institutional Data. The data steward develops the definition and coding structure of the data, insures the data's accuracy and 4

5 De-provisioning FPS Group Account Guest Account IAM IBIS Institutional Data completeness, authorizes access to and establishes data use and protection requirements for the data under his/her control. The term is used in a variety of contexts within the Identity Management realm: The process or archiving and deleting affiliates (users). The process of removing user s access to data, technology resources or services. Friends of Penn State. Is an authentication system that provides identities to users outside of Penn State so that they can access Web-based applications inside of Penn State. An Account, which has a single, Password validly shared by several System Users. Group Accounts must be authorized in writing in accordance with Policy AD20 and are only granted in unusual circumstances. An Account that does not have a specific, individual User ID associated but rather a more generic ID such as "guest." Such accounts are generally intended for temporary use by authorized visitors. Such Accounts must be kept at a minimum and must be restricted to Captive Accounts. Identity and Access Management. Is about aligning policies and processes and the technologies to support managing identities and access to information. Integrated Business Information System. IBIS is the electronic business system used at Penn State, composed of a variety of business applications and systems to provide financial and human resource information. Information that is necessary to the management and operation of Penn State. This information is a University asset, owned by the University and intended to be used solely for the operation of the University in carrying out its mission. 5

6 ISIS LDAP LoA NIST Password PCI Phase 1 Provision/Provisioning Public Records Registration Authority Integrated Student Information System. ISIS, accessible to faculty and staff (not students), is the centralized student system that manages the records for all Penn State students graduate, undergraduate, credit and non-credit at all Penn State locations. Lightweight Directory Access Protocol. LDAP is an application protocol for querying and modifying data using directory services running over TCP/IP. Level of Assurance. It is the degree of certainty of an individual is who they say they are when they present their digital credentials. National Institute of Standards and Technology Something intended for the use of a specific System User, for example, a unique and private alphanumeric character string that validates to a computer or network resource that the System User attempting to access its services is who he/she claims to be. Payment Card Industry. The requirements that have been identified as Phase 1 will be addressed in the first deployment of the Central Person Registry. The first deployment of the CPR will be in a production environment to a limited number of stakeholder participants, followed by an evaluation period. After the evaluation period, an assessment will be made on an enterprise wide deployment of the CPR. Providing or making something available. The term is used in a variety of contexts within the Identity Management realm: The process of creating and maintaining affiliates (users). The process of providing users with access to data, technology resources or services. Publicly distributed information, which is available to anyone. Is an authorized agent that is responsible for vetting user information and issuing 6

7 SoR SRS User ID digital credentials. System of Record, is an system (computer or data), which is the authoritative data source for a given data element or piece of information. Software Requirements Specification The "name" used to identify the user of a computer Account (for example, a unique character string associated with the user). All processes initiated on a computer are attributable to a User ID and, hence, the user holding the User ID is accountable for all actions resulting from processes initiated by that User ID. A User ID is generally the public identification of a System User, unlike a Password, which must be kept private. 7

8 2 Referenced Documents Project Documents Central Person Registry Project Scope and Definition Central Person Registry Phase I Schedule Central Person Registry Software Requirements Specification Full Version Other Documents Identity and Access Management Final Report IAM Use Case Summary 8

9 3 Functional Requirements In the sections that follow you will be presented with the functional requirements for the Central Person Registry. Wikipedia.com defines a functional requirement as a function of a software system or its component. A function is described as a set of inputs, the behavior and outputs. Functional requirements may be calculations, technical details, data manipulations and processing and other specific functionality that define what a system is supposed to accomplish. 3.1 Existing Registries (ER) A number of existing identity registries were examined to determine requirements for the Central Person Registry. Sources of requirements included: requirement specifications, design documentation and in some cases database design. The registries that were examined include: CACTUS - Central Accounts Coordination Tracking of User Services. CACTUS is the database for Access Accounts. FPS - Friend of Penn State. FPS is the registry for Penn State's external authentication accounts. CIDR - Central ID Repository. CIDR contains the mapping of a person's Social Security Number (SSN) to the PSU ID. Each requirement has an identifier that has a prefix of ER, the requirement text and the source of the requirement. Requirement Id Type Category Stage Text ER_00001 The CPR shall support the storage of the partial (MM/DD) and/or full (MM/DD/YYYY) date of ER_00010 ER_00020 ER_00030 ER_00040 birth for a person. The CPR shall use a database generated identification number to identity all entities within its database. The CPR shall support the storage a user's gender. The CPR shall have the ability to associate multiple digital identities (userids) to a single person. The CPR shall have an indicator in its data store as to what is the person s primary digital identity. ER_00045 The CPR shall maintain a history of a person's PSU ID numbers. ER_00060 The CPR shall store a person's 9

10 ER_00070 ER_00080 ER_00090 ER_00100 ER_00110 ER_00120 ER_00130 ER_00035 ER_00700 ER_00710 ER_00720 ER_00730 ER_00050 ER_00140 first, middle and last name and optionally a suffix. The CPR shall maintain a history of a person's names. The CPR shall indicate which is a person's "active" name. The CPR shall support the storage of multiple addresses for a person to include any of the following: employee office and home address, and/or student local and home address. The CPR shall store for an address, the following information: street address, city, state, postal code, country, campus location and source (IBIS/ISIS/others). The CPR shall store if applicable a person's attend last name. The CPR shall support the storage of multiple telephone number to include any of the following: employee office and home address, student local and home address, and a cell phone. The CPR shall store for a phone number the following information: area/country code, phone number, extension (optional) and source. The CPR shall support the storage of a user's address and its type. The CPR shall have audits performed on the database to remove format errors and other inaccuracies. All interfaces to the CPR shall be done via a secure access method The CPR shall not store user passwords The CPR shall provide Web Services to interact with its database. The CPR shall support the storage of a PSU ID. The CPR shall support batch processing of data from Systems 10

11 ER_00150 ER_00160 ER_00170 ER_00200 ER_00280 ER_00310 ER_00360 ER_00370 ER_00400 ER_00420 ER_00430 ER_00440 ER_00450 ER_00460 of Record (SoR). The CPR shall support interactive input information from authorized Registration Authorities via Web Services. The CPR shall support a comments facility for use by Registration Authorities and Security Operations and Services. The severity level associated with a comment shall be one of the following: none, watch, warn, locked, unlocked. The CPR shall maintain a history of a person's addresses. The CPR shall maintain an audit log of all of the activity performed on a user's identity The CPR shall generate a view of data to be used by LDAP. The CPR shall automatically provision a user's digital identity based on business rules. The CPR shall de-provision a user's digital identity based on business rules. The CPR shall store the primary affiliation of all entities in its registry. The CPR shall store the status of all of the services that have been provisioned for a user. The CPR shall log all processing errors of batch feeds from Systems of Record (SoR). The CPR shall generate notifications 30 days prior to a user's expiration of a provisioned service. The CPR shall generate a checksum of any data file it receives from a System of Record (SoR) and compare that against the provided checksum to determine if the file's contents are correct. The CPR shall generate a checksum for any data file is outputs. 11

12 ER_00470 ER_00480 ER_00490 ER_00500 ER_00510 ER_00520 ER_00530 ER_00550 ER_00560 ER_00570 ER_00590 ER_00600 The CPR shall support the archival of user information to another data store. The CPR shall use an algorithm that generates the digital identity userid for a person based on their name. The CPR shall obtain a userid to provision for a user from an identity pool. The CPR shall place in the identity pool, userids that are available for assignment due to holes in the existing identity space. The CPR shall keep track of all policies that are agreed upon by the user. The system shall assign PSU Id numbers within the range through The system shall assign PSU Id numbers from the available numbers randomly so that it will not be possible to guess, calculate or derive the value of Id number from knowledge about the user name, the time in history that the Id was assigned or any other means. The system shall have a service that allows matching decisions to be made within a batch processes. Each data element stored by the system shall have a specified format and/or a range of values. The system shall have an address verification service. The system shall use a fuzzy logic searching capability to remove differences between data values entered into selected data elements with free format text entry. The system shall have a set of rules for cleansing and standardizing data before it is entered into the data repository. ER_00610 The system shall include a data 12

13 ER_00640 ER_00650 ER_00660 ER_00670 ER_00680 ER_00690 ER_01000 ER_01030 ER_01040 ER_02020 ER_02030 ER_02040 ER_02050 ER_02070 ER_02080 ER_02090 ER_02100 element for place of birth. The system shall have a set of services to interface with the CIDR system. The system shall have a set of criteria for evaluating the quality of a near match. The system shall have a service to merge multiple identities. The system shall retain sufficient information about merges for auditing purposes. The system shall have a service to reassign a different PSU Id. The system shall retain sufficient information about identity reassigns for auditing purposes. The CPR shall support the assignment and storage of a PSU ID. The CPR shall provide a mechanism to update information. The CPR shall store a type for a data element that has multiple values to distinguish between the individual values. The CPR shall support the retrieval of person information. The CPR shall support the archival of a person. The CPR shall support the establishment of confidentiality for employees and students. The CPR shall support the storage of employee and student biographical information. The CPR shall support a facility to allow for read-only views of its data to be accessed by authorized entities. The CPR shall support a facility to provision and de-provision sponsored accounts. A CPR's sponsored account shall have a supervisor who may or may not be a registration authority. A CPR's sponsored account shall have a defined lifetime for each of 13

14 ER_02110 ER_02120 ER_02130 ER_02140 its users. The CPR shall support the storage of ID+ card information. The CPR shall accept a Social Security Number for purposes of passing it through to CIDR for storage. The CPR shall support the mapping between Penn State Identity Assurance Profiles (IAP) and external (InCommon) IAPs. The CPR shall support the storage of data elements as defined by Penn State guest, bronze and silver identity assurance profiles (IAP). 3.2 Regulations and Legislation (RL) This section contains requirements that were gathered from reviewing policies and procedures, and government regulations and legislation. The sources for these requirements can be found at the following locations: University Policy AD11 - University Policy on Confidentiality of Student Records University Policy AD19 - Use of Penn State Identification Number and Social Security Number University Policy AD20 - Computer and Network Security University Policy AD23 - Use of Institutional Data University Policy AD35 - University Archives and Records Management University Policy AD22 - Health Insurance Portability and Accountability Act (HIPAA) HEOA - Higher Education Opportunity Act Red Flag Rules PCI - Payment Card Industry Each requirement has an identifier that has a prefix of RL, the requirement text and the source of the requirement. RL_00180 REGS & LEGS A single CPR record (constructed from multiple data sources) shall be associated with one individual. RL_00190 REGS & LEGS The CPR shall support a preferred communication method related to health matters. RL_00200 REGS & LEGS The CPR shall provide a means to restrict use and disclosure of Protected Health Information. RL_00110 REGS & LEGS All processes initiated by the CPR shall be uniquely attributable to an account of a distinct system 14

15 user. RL_00120 REGS & LEGS Data elements of the CPR shall be classified as confidential or nonconfidential in accordance with law and university policy. RL_00100 REGS & LEGS All CPR data elements shall be protected from unauthorized modification, destruction or disclosure, whether accidental or intentional. RL_00020 REGS & LEGS The CPR shall not store Social Security numbers (SSN). RL_00030 REGS & LEGS The CPR shall use the Penn State Identification Number (PSU ID) as the primary identification number for students and employees. RL_00040 REGS & LEGS The CPR shall make efforts to prevent assignment of multiple PSU IDs to the same individual. RL_00050 REGS & LEGS The CPR shall treat the PSU ID as non public information. RL_00060 REGS & LEGS The CPR shall require certain minimum information about the individual as prescribed by the Data Steward to assign a PSU ID. RL_00070 REGS & LEGS The CPR shall notify constituents of their new PSU ID in a timely manner, using consistent methods and wording as specified by the Data Stewards. RL_00080 REGS & LEGS The CPR shall provide a mechanism of replacing a PSU ID should it be compromised and used fraudulently, subject to the review and approval of the Chief Privacy Officer. RL_00100 REGS & LEGS The CPR shall protect against unauthorized modification of information. RL_00160 REGS & LEGS The CPR shall define/implement a Data retention policy for CPR data dependent on the data element. RL_00210 REGS & LEGS The CPR shall verify phone number provided is in a valid format. RL_00280 REGS & LEGS The CPR shall not store, transmit, nor process any PCI related data. 15

16 RL_00001 REGS & LEGS The CPR shall distinguish between directory and nondirectory information in accordance with the definition of public data described by AD11. RL_00010 REGS & LEGS The CPR shall have some means of determining if a request has been filed to block public access to a student s directory data and the date the request was filed. RL_00230 REGS & LEGS The CPR shall provide a facility to allow for monitoring the activity on the account of deceased user. Any use must be reported as a Red Flag violation. RL_00240 REGS & LEGS The CPR shall provide a function that allows University personnel to deactivate an account on the event of a RED FLAG violation RL_00250 REGS & LEGS The CPR shall track for audit purposes when/why an account is deactivated RL_00260 REGS & LEGS The CPR shall provide a function that allows University personnel to enable/disable monitoring of activity on an account. A University employee should be able to request an audit of the account. ER_00410 UNIVERSITY The CPR shall store all of the affiliations a person has. 3.3 University Specific Information (US) This section contains requirements that were gathered from a number of University sources, some of which include: CPR Interview Sessions - there were a total of four sessions that were held that were open forums where stakeholders could come and discuss with the IAM TAG team the results of their survey, and other topics. CPR Survey - A twenty-nine-question survey was sent out of a number of key stakeholders during the December January 2010 timeframe to be used as a basis for gathering additional requirements. Respondents were surveyed about things they needed to move to a Central Person Registry along with other requirements for access and timeliness. IAM Reports - A number of IAM reports were generated as a precursor to the IAM Final Report (dated February 18, 2008). These reports were from the following groups: o Life Cycles and Affiliations o Vetting, Proofing, and Registration Authorities o Levels of Assurances (LoA) 16

17 o Risk Assessment o Governance and Policy for Managing Identity and Access IAM Worksheet - developed at the an IAM stakeholders meeting Student Lifecycle - draft recommendations from the IAM Student Lifecycle Committee Use Cases - gathered from stakeholders (see Appendix for listing). Each requirement has an identifier that has a prefix of US, the requirement text and the source of the requirement. US_00840 UNIVERSITY THE CPR shall assign a LoA for each data element in the CPR. US_00770 UNIVERSITY The CPR shall base affiliations on types of relationships with the University; they should not be defined by the specific University organization element involved. US_00780 UNIVERSITY The CPR affiliations shall have additional attributes based on defined vocabularies. US_00790 UNIVERSITY The CPR shall not delete affiliations. US_00800 UNIVERSITY The CPR shall be able to deactivate affiliations when they are no longer valid or apply. US_00810 UNIVERSITY The CPR shall support the reactivation of affiliations if the need arises. US_00820 UNIVERSITY The CPR shall automatically provision affiliations and their supporting attributes. US_00830 UNIVERSITY The CPR shall audit at a minimum for affiliation changes, the following: Date-time of assignment/deactivation/reactivati on/any change; relevant data; user making the change. US_00860 UNIVERSITY The PsuPerson LDAP object class shall be extended for the addition of a new attribute to hold the various aspects of a student s affiliation US_00180 UNIVERSITY The IAP shall be stored centrally along with the digital identity (userid). US_00340 UNIVERSITY The CPR shall be updated real or near real time (consider SOA principles) NR_00010 UNIVERSITY The system shall have a data 17

18 dictionary. US_00600 UNIVERSITY The CPR shall require that upon re-credentialing an individual be assigned an IAP commensurate with the information provided during the re-credentialing process. US_02000 UNIVERSITY The CPR shall adhere to the requirements set forth in the IAM student Lifecycle final report. US_02010 UNIVERSITY The CPR shall adhere to the requirements set forth in the IAM Non-student Lifecycle Final Report US_00620 UNIVERSITY The system shall be able to identify all identity provisioners PR_00020 UNIVERSITY The system shall have the capability of requiring an Identity Assurance Profile (IAP), formerly known as LoA for each application or service. US_00650 UNIVERSITY The system shall have the flexibility to accommodate transitional periods when a user is moving from on position to another. US_00670 UNIVERSITY The system shall support provisioning/de-provisioning across life cycles (e.g. retirees who are still working) US_00150 UNIVERSITY The CPR shall provide interfaces that are readily accessible from the mainframe and local processing systems and should return a standard collection of data. US_00030 UNIVERSITY The CPR shall provide a mechanism for service providers to learn about updates to data. US_00200 UNIVERSITY The CPR shall provide information about Hershey populations. US_00210 UNIVERSITY The CPR shall provide a selfservice registration application similar to what FPS provides today. US_00010 UNIVERSITY The CPR shall not allow for duplication of data. US_00250 UNIVERSITY The CPR shall maintain a single 18

19 digital identity (userid, PSU ID) for the lifetime of the student. US_00260 UNIVERSITY The CPR shall provide migration from one authorization level to another that is automatic and seamless. US_00270 UNIVERSITY The CPR shall provide a mechanism for students to be able to reset their passwords through all stages of the student lifecycle. US_00290 UNIVERSITY The CPR shall provide central management of password changes, with appropriate customer service for students at a distance. US_00310 UNIVERSITY The CPR shall provide real-time access, verification and updating. US_00330 UNIVERSITY The CPR shall provide access to its data using any/all of the following mechanisms: A6CIDRBAT, LDAP, XML, REST, SOAP, Web Service, publish and subscribe, JDBC (read-only). US_00340 UNIVERSITY The CPR shall perform real-time updates of its data that is received from Systems of Record (SoR). US_00350 UNIVERSITY The CPR shall provide reliable and accurate matching. US_00360 UNIVERSITY The CPR shall provide a facility to update match-related information, like address history, gender, DOB and name history. ER_00540 UNIVERSITY The CPR shall provide the facility to look up a person based on their PSU ID, digital identity (userid/psu ID) or available match data. US_00110 UNIVERSITY The CPR shall provide a mechanism to mark a record as a candidate for archival or deletion. US_00090 UNIVERSITY The CPR shall record the registration authority that created an identity. US_00100 UNIVERSITY The CPR shall provide interfaces for account management US_00110 UNIVERSITY The CPR shall archive inactive users allowing for easy reinstatement for temporary 19

20 rehires. US_00130 UNIVERSITY The CPR shall provide a means to administer accounts for students at other institutions for example, student interns from South Hills US_00001 UNIVERSITY The CPR shall distinguish between international and noninternational data for matching purposes. US_00020 UNIVERSITY The CPR shall support the storage of multiple appointment data for employees. US_00030 UNIVERSITY The CPR shall provide a notification service for any and/or all changes related to a person s information. US_00040 UNIVERSITY The CPR shall provide a mechanism to provide services for personnel that have no official affiliation with the University. US_00050 UNIVERSITY The CPR shall provide a facility to easily re-activate an account for a returning student. US_00060 UNIVERSITY The CPR shall provide support and storage of information for the following groups of people: retirees, visiting scientists/faculty, outside auditors, vendors and volunteers. US_00030 UNIVERSITY The CPR shall support services that notify stakeholders of a user s change in status. US_00060 UNIVERSITY The CPR shall support the provisioning of identities for affiliates (like volunteers). US_00200 UNIVERSITY The CPR shall accurately represent the employment status of all Hershey Medical Center employees. US_00720 UNIVERSITY The CPR shall accurately represent the type of a technical service employees contained within its registry. US_00960 UNIVERSITY The CPR shall have an affiliation that represents alumni donor volunteers. US_00970 UNIVERSITY The CPR shall include an affiliation that represents Alumni Association member. 20

21 US_00730 UNIVERSITY The CPR shall provide a means for identifying student interns (so that they can gain access to Human Resource systems.) US_00720 UNIVERSITY The CPR shall maintain an accurate employment status for wage payroll employees. (Currently status is determined by examining last pay date.) US_00410 UNIVERSITY All registration authorities shall require the same data for creating a record at a specified IAP. US_00750 UNIVERSITY The CPR shall provide a linkage between various accounts: student/parent, employee/spouse, employee/dependents US_00750 UNIVERSITY The CPR shall provide a service for delinking various accounts (student/parent,employee/spouse, employee/dependents) US_00050 UNIVERSITY The CPR will reuse the same access id if an individual resumes a relationship with the university after many years. POL_00100 UNIVERSITY The CPR shall require as much data as is needed and allowed by policy to ensure reliable matching of records. US_00920 UNIVERSITY The CPR shall provide a clear indicator that a record has been transferred to a surviving spouse. US_00080 UNIVERSITY The CPR shall flag records that match a SSN in CIDR if other match data is inconsistent for further review. ER_01010 UNIVERSITY The CPR shall support the functionality to store a person s address. US_00880 GENERAL The CPR shall support the publishing of information to external sources in mixed case. US_00870 GENERAL The CPR shall support the ability for a user to indicate what elements of their directory information is public to the world vs. internal to Penn State. US_01050 GENERAL The CPR shall provide a mechanism for an individual to request that their non system 21

22 critical data be expunged from the system. ER_02060 GENERAL The CPR shall support message communications between service providers. 3.4 External (EXT) This section contains requirements that were gathered from sources external to Penn State. They include the following: eduperson LDAP objectclass InCommon Identity Assurance Profile (IAP) Each requirement has an identifier that has a prefix of EXT, the requirement text and the source of the requirement. EXT_00020 EXTERNAL THE CPR shall assign all of a person's relationship(s) to the institution in the edupersonaffiliation - allowable values faculty, student, staff, alum, member, affiliate, employee, library-walk. EXT_00060 EXTERNAL THE CPR shall assign a value to edupersonprincipalname in the form of formuser@domain. EXT_00001 EXTERNAL THE CPR shall assign a value to givenname. EXT_00001 EXTERNAL The CPR shall assign a value to displayname. EXT_00001 EXTERNAL The CPR shall assign a value to mail. EXT_00001 EXTERNAL The CPR shall populate for people, information in the person, organizationalperson, and inetorgperson objectclasses. EXT_00010 EXTERNAL The CPR shall populate the edupersonprimaryaffiliation attribute for entities that have a relationship with the University. EXT_00020 EXTERNAL The edupersonprimaryaffiliation values shall be limited to faculty, student, alum, member, affiliate, employee and library-walk-in. EXT_00030 EXTERNAL The CPR shall populate all of a user's affiliations in the edupersonaffiliation attribute 22

23 (see edupersonprimaryaffilation for a definition of the values). EXT_00040 EXTERNAL The CPR shall populate the edupersonentitlement attribute to indicate a user's set of rights to specific resources. EXT_00050 EXTERNAL The CPR shall support the storage of information populated in the edupersonnickname attribute. EXT_00060 EXTERNAL The CPR shall populate the edupersonprinciplename attribute for all users. It shall be represented in the form of "user@scope" where scope defines a local security domain. EXT_00070 EXTERNAL The CPR shall populate the edupersonassurance attribute for each user. It will be based on their Identity Assurance Profile (IAP) and will contain a set of URIs that assert compliance with specific standards for identity assurance. EXT_00080 EXTERNAL The CPR shall populate a person's edupersonorgunitdn which represents all of the DNs of directory entries representing a person's Organizational Units (pointers to Departmental Identity). EXT_00090 EXTERNAL The CPR shall populate a person's edupersonprimaryorgunitdn, which is the DN of the directory entry representing the person's primary Organization Unit (pointer to entry in Departmental Identity). EXT_00100 EXTERNAL The CPR shall provide controls on access and changes to critical data EXT_00230 EXTERNAL As defined by InCommon, the CPR at a minimum shall log date, time, nature and outcome of all significant events. The logs must be kept for 6 months to be compliant with the federation. EXT_00130 EXTERNAL Shared secret shall have at least 10 bits of min-entropy to protect against an untargeted attack. 23

24 EXT_00150 EXTERNAL The CPR shall provide detect and mitigate a suspected or attempted credential compromise. US_00990 USE CASE The system shall have the capability for providing access to services and programs for accepted freshmen in the semester before classes begin. US_00990 USE CASE The system shall have the capability of establishing identities for prospective students at first contact with the university. US_01000 USE CASE The system shall have the capability of automatically performing an assessment based on a students status in the digital lifecycle and making available a collection of services that is consistent with that status. PR_00090 USE CASE The system shall have the capability of providing services for athletic coaches who are paid as university employees for short periods of time (possibly seasonal) during the calendar year, but have job responsibilities that require access to university services the entire year (for example, for recruiting purposes) US_00130 USE CASE The system shall be able to provide services to individuals working as either paid or unpaid interns at the university. US_01010 USE CASE The system shall be able to provide services to instructors who work at the university on a contract basis for one semester (continuous or one time). Services should be available to the instructor for a sufficient time period before and after the contract dates to allow for course preparation and follow up. POL_00140 USE CASE The system shall be able to provide for the provisioning of appropriate levels of services for employees with an IBIS status of retired but are now working as emergency rehires. 24

25 POL_00200 USE CASE The system shall permit the establishment of associations between a student and parent (or guardian) that provide a level of service access to the parent that is consistent with FERPA regulations and the desires of the student. 25

26 4 Non-functional Requirements In the section that follows, you will be presented with the non-functional requirements for the CPR. Wikipedia.com defines a non-functional requirement as a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. In effect, they are related to the qualities of a system. They are typically divided into two categories: Execution qualities, such as security and usability, which are observed at run time. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of a software system. 4.1 Non-functional Requirements (NR) Each requirement has an identifier that has a prefix of NR, the requirement text and the source of the requirement. NR_00720 NR_00730 NR_00740 NR_00540 NR_00710 NR_00410 NR_00420 NR_00430 USE CASE CPR shall provide a proxy for supervisor of sponsored accounts. The CPR shall limit the possibility of creating multiple EXISTING EXISTING REGS & LEGS REGS & LEGS REGS & LEGS records for all levels of assurance. The CPR shall provide a process for changing the default password policy for individual records. The CPR shall be able to adapt to any new university policies. The CPR shall provide a featurerich set of web services to enable interaction with its data store. The system shall not contain department specific data elements. A data steward shall be assigned to each data element in the CPR. The CPR shall include protection for privacy of information. The CPR shall define/implement a Data retention policy for Web Server Logs that adheres to University and external policies. NR_00440 REGS & LEGS The CPR shall define/implement a Data retention policy for Web Session Logs that adheres to University and external policies. NR_00460 REGS & LEGS The system shall adequately 26

27 NR_00470 NR_00510 NR_00520 NR_00530 NR_00450 NR_00480 NR_00030 NR_00040 REGS & LEGS REGS & LEGS REGS & LEGS REGS & LEGS UNIVERSITY UNIVERSITY UNIVERSITY UNIVERSITY protect the privacy and integrity of data when transmitted on communication channels. The system shall require written agreements on institutional data use and protection between the individual requiring access to institutional data, their access and security representative (ASR) and the applicable data steward prior to the release of such data to any individual. Ensuring mechanisms are in place to obtain acknowledgment from System Users that they understand, and agree to comply with University and College/Unit security policies. Such acknowledgment must be written unless an exception is approved in accordance with the Exceptions and Exemptions section of this policy. Ensuring technical or procedural means are in place to facilitate determining the User ID responsible for unauthorized activity in the event of a security incident. Taking reasonable precautions, including personal password maintenance and file protection measures, to prevent unauthorized use of their accounts, programs or data by others. There shall be a single central person registry for all registration processes within the University. The official data sources (systems of record) for the systems data elements shall be defined. There shall be continuity of operations during the transition from old repositories to the new system. The system shall have a set of metrics and standards with which to assess performance and efficacy. 27

28 NR_00490 NR_00500 NR_00550 NR_00560 NR_00020 NR_00570 NR_00580 NR_00050 NR_00690 NR_00100 NR_00110 NR_00120 NR_00130 NR_00001 NR_00140 NR_00150 UNIVERSITY UNIVERSITY UNIVERSITY UNIVERSITY UNIVERSITY UNIVERSITY UNIVERSITY UNIVERSITY UNIVERSITY The CPR will be a complete and up-to-date person record for each individual University member or affiliate. The CPR services will be available to application providers for the real-time provisioning of access. The system data elements shall be updated from authoritative sources The system shall have a welldefined communications stream for provisioning/deprovisioning. The system shall support multiple factor authentication technologies. The system shall have a data retention policy consistent with archival policies of the university. The system shall have a streamlined "code red" deprovisioning process. The system shall be able to provide a digital credential within two hours. The CPR shall ensure that identity data remain within the canonical source and not maintain additional data sets with the same data. GENERAL The CPR shall be open, extensible and scalable. GENERAL The CPR shall handle all errors by reporting appropriate responses to the end user and an internal log. GENERAL The CPR shall provide a database to store information about users. GENERAL The CPR shall provide a featurerich set of web services to enable interaction with its data store. GENERAL The CPR shall be highly available 24/7/365. GENERAL The CPR shall be redundant by having a copy of its data store at an off-site location. GENERAL The CPR shall limit nonemergency outages to the ITS "maintenance window". 28

29 NR_00160 NR_00170 NR_00180 NR_00190 NR_00200 NR_00210 NR_00220 NR_00230 NR_00240 NR_00400 GENERAL The CPR shall provide fault tolerant features to include: mirrored file systems, file system backups and database backups. GENERAL The CPR shall adhere to FERPA, HIPAA, and COPPA regulations in the area of data collection and retention. GENERAL The CPR shall be backed up at the file system and database levels. GENERAL The CPR machine(s) shall only run the necessary services for its operation. GENERAL The CPR system and database administrators shall maintain the physical security of the network and the server hardware. GENERAL The CPR administrators shall provide procedures for monitoring the functionality of the server and methods to alert appropriate personnel if the server should become unavailable. GENERAL The CPR administrators shall monitor the security of the server, checking logs, running appropriate security tools, etc. GENERAL The CPR administrators shall provide at least 1 business day advance warning to stakeholders when conducting routine maintenance that may impact the operation of the service. GENERAL The CPR administrators shall ensure that the CPR server has the latest software patches and fixes. GENERAL The CPR database shall support international character sets. 29

30 5 Future Requirements Other requirements will be added when they are identified. Some future areas for requirements include: IAM Non-Student Lifecycle Final Report IAM Hershey Medical Center Committee 30

31 6 Appendix 1 Use Case List Id Use Case 1 Access to Protected Library Resources 2 Library Staff Access to Integrated Library System 3 Access to Library Public Workstations 4 HMC Affiliate Access to Library Resources 5 Access to Alumni Library Resources 6 Access to Electronic Theses and Dissertations Web Site 7 Graduate School Exit Survey 8 Federating to blogging hosted services 9 Prospective students applying for financial aid 10 Employee confidentiality 11 Provisioning of an employee's digital identity 12 Student early access to resident hall requests and immunization records submissions 13 Grouper auditing 14 Continuing Education and Adult Students 15 New students applying for admissions and on-campus housing 16 Prospective students visiting Penn State New Kensington 17 New faculty and access to ANGEL and other class resources 18 Adjunct Faculty activating Access Account 19 New faculty & staff selecting benefits 20 Terminated faculty member maintains access Physicians at the Hershey Medical Center and Access to Library Resources Patients, Family Members, and Visitors at the Penn State Hershey Medical Center 23 Alumni Donors 24 Alumni Association 25 Local community member and short term access accounts 26 Registrar relationships 27 Student life cycle 28 New students applying for undergraduate admissions 29 Provision of Access to Course Work For Students at a Distance 30 Library resources 31 ITS Computer Store Access 31

32 32 CIC Courseshare 33 Deprovision User content after graduation or resignation 34 Google cache updates 35 Access to user content after graduation and/or resignation 36 Access to directory data 37 Emergency rehire 38 Multiple IDs 39 Deceased Employees 40 Outreach Registration Process 41 Updating ISIS security profile 42 Multiple Security Realms, Same Userids but Different Passwords 43 ROTC Instructor Affiliation 44 Instructor with independent contractor status 45 Name change switching in the directory 46 Special affiliates (for example Religious affiliates) 47 Father and son who is a Jr. 48 Cloning ISIS security profiles 49 New PSUid assigned for new PSU affiliation 50 Student Football Tickets 51 Departmental Identity 52 DSL Use Case Interview 53 Police Services Use Case 54 Missing Student 55 Employee switches job from CPR Survey 56 Digital Identity for Volunteers from CPR Survey 57 Digital Identity Problems with loan borrowers from CPR Survey 58 HMC Employees access to PCARD Test 59 Technical Services Employees Access to downloads.its.psu.edu 60 Stringent Controls for Accessing IBIS and ISIS Data Disappears With Other Applications 61 CE Alumni Survey 62 Orion students from CPR Survey 63 Distance Education for Students in Military from CPR Survey 64 PreProspect or Prospect Digital Lifecycle from CPR Survey 65 Level of assurance based authorization from CPR Survey 66 Part Time Sports Coaches from CPR Survey 32

33 67 Internships for non-penn State Students from CPR Session 1 68 Instructors teaching one semester a year from CPR Session 3 69 Multiple Affiliations from CPR Session 3 70 Student confidentiality from CPR Session 3 33