central person registry · pdf filecentral person registry requirements 1 ... • a set of...

Central Person Registry Requirements

1

Identity and Access Management

Central Person Registry

Software Requirements Specification

22 September 2011


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&,-"' <!()!! &=*"-*,>'4&>*"-4*&"'?&4@' <!()0! 4&>6:/-*$,"'/,+':&>*":/-*$,'?4:@' !7!()(! 6,*3&4"*-1'"%&#*.*#'*,.$42/-*$,'?6"@' !A!()7! &=-&4,/:'?&=-@' 00!7! ,$,B.6,#-*$,/:'4&;6*4&2&,-"' 0A!7)!! ,$,B.6,#-*$,/:'4&;6*4&2&,-"'?,4@' 0A!C! .6-64&'4&;6*4&2&,-"' (D!A! /%%&,+*='!'6"&'#/"&':*"-' (!!


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.

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.

Systems of

Record

Registration Authorities

Web Services

Service Providers

Data Views

Database

Central Person Registry


4

1.3 Document Overview This document is composed of four sections:

• Scope • Referenced Documents • Requirements • Appendices

1.4 Terms and Abbreviations

Term Definition

Access and Security Representative

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.

Account

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

CACTUS Central Accounts Coordination Tracking of User Services. This is the database for Access Accounts.

Captive Account

An Account where the user can access a restricted list of application programs only and has, at most, restricted network access.

CIDR

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.

Computerized Institutional Data Institutional Data that is captured, stored, maintained, accessed or used by a computer system.

CPR Central Person Registry.

Data Steward

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


5

completeness, authorizes access to and establishes data use and protection requirements for the data under his/her control.

De-provisioning

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.

FPS

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.

Group Account

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.

Guest Account

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.

IAM

Identity and Access Management. Is about aligning policies and processes and the technologies to support managing identities and access to information.

IBIS

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.

Institutional Data

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.


6

ISIS

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.

LDAP

Lightweight Directory Access Protocol. LDAP is an application protocol for querying and modifying data using directory services running over TCP/IP.

LoA

Level of Assurance. It is the degree of certainty of an individual is who they say they are when they present their digital credentials.

NIST National Institute of Standards and Technology

Password

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.

PCI Payment Card Industry.

Phase 1

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.

Provision/Provisioning

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.

Public Records Publicly distributed information, which is available to anyone.

Registration Authority Is an authorized agent that is responsible for vetting user information and issuing


7

digital credentials.

SoR

System of Record, is an system (computer or data), which is the authoritative data source for a given data element or piece of information.

SRS Software Requirements Specification

User ID

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.


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


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 FUNCTIONAL EXISTING

REGISTRY One The CPR shall support the storage

of the partial (MM/DD) and/or full (MM/DD/YYYY) date of birth for a person.

ER_00010 FUNCTIONAL EXISTING REGISTRY

One The CPR shall use a database generated identification number to identity all entities within its database.


One The CPR shall support the storage a user's gender.


Two The CPR shall have the ability to associate multiple digital identities (userids) to a single person.


Two The CPR shall have an indicator in its data store as to what is the person’s primary digital identity.


One The CPR shall maintain a history of a person's PSU ID numbers.

ER_00060 FUNCTIONAL EXISTING One The CPR shall store a person's


10

REGISTRY first, middle and last name and optionally a suffix.


One The CPR shall maintain a history of a person's names.


One The CPR shall indicate which is a person's "active" name.


One 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.


One The CPR shall store for an address, the following information: street address, city, state, postal code, country, campus location and source (IBIS/ISIS/others).


Two The CPR shall store if applicable a person's attend last name.


One 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.


One The CPR shall store for a phone number the following information: area/country code, phone number, extension (optional) and source.


One The CPR shall support the storage of a user's email address and its type.


Three The CPR shall have audits performed on the database to remove format errors and other inaccuracies.


One All interfaces to the CPR shall be done via a secure access method


One The CPR shall not store user passwords


One The CPR shall provide Web Services to interact with its database.


One The CPR shall support the storage of a PSU ID.


Three The CPR shall support batch processing of data from Systems


11

of Record (SoR). ER_00150 FUNCTIONAL EXISTING

REGISTRY One The CPR shall support interactive

input information from authorized Registration Authorities via Web Services.


Two The CPR shall support a comments facility for use by Registration Authorities and Security Operations and Services.


Two The severity level associated with a comment shall be one of the following: none, watch, warn, locked, unlocked.


One The CPR shall maintain a history of a person's addresses.


Three The CPR shall maintain an audit log of all of the activity performed on a user's identity


Three The CPR shall generate a view of data to be used by LDAP.


Three The CPR shall automatically provision a user's digital identity based on business rules.


Three The CPR shall de-provision a user's digital identity based on business rules.


One The CPR shall store the primary affiliation of all entities in its registry.


Three The CPR shall store the status of all of the services that have been provisioned for a user.


Three The CPR shall log all processing errors of batch feeds from Systems of Record (SoR).


Three The CPR shall generate E-mail notifications 30 days prior to a user's expiration of a provisioned service.


Three 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.


Three The CPR shall generate a checksum for any data file is outputs.


12


Three The CPR shall support the archival of user information to another data store.


One The CPR shall use an algorithm that generates the digital identity userid for a person based on their name.


Two The CPR shall obtain a userid to provision for a user from an identity pool.


Two The CPR shall place in the identity pool, userids that are available for assignment due to holes in the existing identity space.


Three The CPR shall keep track of all policies that are agreed upon by the user.


One The system shall assign PSU Id numbers within the range 900000000 through 999999999


One 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.


Three The system shall have a service that allows matching decisions to be made within a batch processes.


Three Each data element stored by the system shall have a specified format and/or a range of values.


Two The system shall have an address verification service.


Two 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.


Three The system shall have a set of rules for cleansing and standardizing data before it is entered into the data repository.

ER_00610 FUNCTIONAL EXISTING Three The system shall include a data


13

REGISTRY element for place of birth. ER_00640 FUNCTIONAL EXISTING

REGISTRY Three The system shall have a set of

services to interface with the CIDR system.


One The system shall have a set of criteria for evaluating the quality of a near match.


Two The system shall have a service to merge multiple identities.


Three The system shall retain sufficient information about merges for auditing purposes.


Two The system shall have a service to reassign a different PSU Id.


Three The system shall retain sufficient information about identity reassigns for auditing purposes.


One The CPR shall support the assignment and storage of a PSU ID.


One The CPR shall provide a mechanism to update information.


One The CPR shall store a type for a data element that has multiple values to distinguish between the individual values.


One The CPR shall support the retrieval of person information.


One The CPR shall support the archival of a person.


Two The CPR shall support the establishment of confidentiality for employees and students.


Two The CPR shall support the storage of employee and student biographical information.


Three The CPR shall support a facility to allow for read-only views of its data to be accessed by authorized entities.


Three The CPR shall support a facility to provision and de-provision sponsored accounts.


Three A CPR's sponsored account shall have a supervisor who may or may not be a registration authority.


Three A CPR's sponsored account shall have a defined lifetime for each of


14

its users. ER_02110 FUNCTIONAL EXISTING

REGISTRY Two The CPR shall support the storage

of ID+ card information. ER_02120 FUNCTIONAL EXISTING

REGISTRY Two The CPR shall accept a Social

Security Number for purposes of passing it through to CIDR for storage.


Two The CPR shall support the mapping between Penn State Identity Assurance Profiles (IAP) and external (InCommon) IAPs.


Two 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 FUNCTIONAL REGS & LEGS Three A single CPR record (constructed from multiple data sources) shall be associated with one individual.

RL_00190 FUNCTIONAL REGS & LEGS Three The CPR shall support a “preferred” communication method related to health matters.

RL_00200 FUNCTIONAL REGS & LEGS Three The CPR shall provide a means to restrict use and disclosure of Protected Health Information.

RL_00110 FUNCTIONAL REGS & LEGS One All processes initiated by the CPR shall be uniquely attributable to an account of a distinct system


15

user. RL_00120 FUNCTIONAL REGS & LEGS Three Data elements of the CPR shall be

classified as confidential or non-confidential in accordance with law and university policy.

RL_00100 FUNCTIONAL REGS & LEGS Three All CPR data elements shall be protected from unauthorized modification, destruction or disclosure, whether accidental or intentional.

RL_00020 FUNCTIONAL REGS & LEGS One The CPR shall not store Social Security numbers (SSN).

RL_00030 FUNCTIONAL REGS & LEGS One The CPR shall use the Penn State Identification Number (PSU ID) as the primary identification number for students and employees.

RL_00040 FUNCTIONAL REGS & LEGS Three The CPR shall make efforts to prevent assignment of multiple PSU IDs to the same individual.

RL_00050 FUNCTIONAL REGS & LEGS One The CPR shall treat the PSU ID as non public information.

RL_00060 FUNCTIONAL REGS & LEGS Two The CPR shall require certain minimum information about the individual as prescribed by the Data Steward to assign a PSU ID.

RL_00070 FUNCTIONAL REGS & LEGS Three 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 FUNCTIONAL REGS & LEGS Three 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 FUNCTIONAL REGS & LEGS Three The CPR shall protect against unauthorized modification of information.

RL_00160 FUNCTIONAL REGS & LEGS Three The CPR shall define/implement a Data retention policy for CPR data dependent on the data element.

RL_00210 FUNCTIONAL REGS & LEGS One The CPR shall verify phone number provided is in a valid format.

RL_00280 FUNCTIONAL REGS & LEGS One The CPR shall not store, transmit, nor process any PCI related data.


16

RL_00001 FUNCTIONAL REGS & LEGS Three The CPR shall distinguish between directory and non-directory information in accordance with the definition of public data described by AD11.

RL_00010 FUNCTIONAL REGS & LEGS Three 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 FUNCTIONAL REGS & LEGS Three 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 FUNCTIONAL REGS & LEGS Three The CPR shall provide a function that allows University personnel to deactivate an account on the event of a RED FLAG violation

RL_00250 FUNCTIONAL REGS & LEGS Three The CPR shall track for audit purposes when/why an account is deactivated

RL_00260 FUNCTIONAL REGS & LEGS Three 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 FUNCTIONAL UNIVERSITY One 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 2009- 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)


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 FUNCTIONAL UNIVERSITY Three THE CPR shall assign a LoA for each data element in the CPR.

US_00770 FUNCTIONAL UNIVERSITY One 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 FUNCTIONAL UNIVERSITY Two The CPR affiliations shall have additional attributes based on defined vocabularies.

US_00790 FUNCTIONAL UNIVERSITY One The CPR shall not delete affiliations.

US_00800 FUNCTIONAL UNIVERSITY Three The CPR shall be able to deactivate affiliations when they are no longer valid or apply.

US_00810 FUNCTIONAL UNIVERSITY Three The CPR shall support the reactivation of affiliations if the need arises.

US_00820 FUNCTIONAL UNIVERSITY Three The CPR shall automatically provision affiliations and their supporting attributes.

US_00830 FUNCTIONAL UNIVERSITY Three The CPR shall audit at a minimum for affiliation changes, the following: Date-time of assignment/deactivation/reactivation/any change; relevant data; user making the change.

US_00860 FUNCTIONAL UNIVERSITY Three 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 FUNCTIONAL UNIVERSITY Two The IAP shall be stored centrally along with the digital identity (userid).

US_00340 FUNCTIONAL UNIVERSITY One The CPR shall be updated real or near real time (consider SOA principles)

NR_00010 FUNCTIONAL UNIVERSITY One The system shall have a data


18

dictionary. US_00600 FUNCTIONAL UNIVERSITY Three 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 FUNCTIONAL UNIVERSITY Three The CPR shall adhere to the requirements set forth in the IAM student Lifecycle final report.

US_02010 FUNCTIONAL UNIVERSITY Three The CPR shall adhere to the requirements set forth in the IAM Non-student Lifecycle Final Report

US_00620 FUNCTIONAL UNIVERSITY Three The system shall be able to identify all identity provisioners

PR_00020 FUNCTIONAL UNIVERSITY Three The system shall have the capability of requiring an Identity Assurance Profile (IAP), formerly known as LoA for each application or service.

US_00650 FUNCTIONAL UNIVERSITY Three The system shall have the flexibility to accommodate transitional periods when a user is moving from on position to another.

US_00670 FUNCTIONAL UNIVERSITY Three The system shall support provisioning/de-provisioning across life cycles (e.g. retirees who are still working)

US_00150 FUNCTIONAL UNIVERSITY One 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 FUNCTIONAL UNIVERSITY Three The CPR shall provide a mechanism for service providers to learn about updates to data.

US_00200 FUNCTIONAL UNIVERSITY Three The CPR shall provide information about Hershey populations.

US_00210 FUNCTIONAL UNIVERSITY Three The CPR shall provide a self-service registration application similar to what FPS provides today.

US_00010 FUNCTIONAL UNIVERSITY Three The CPR shall not allow for duplication of data.

US_00250 FUNCTIONAL UNIVERSITY Two The CPR shall maintain a single


19

digital identity (userid, PSU ID) for the lifetime of the student.

US_00260 FUNCTIONAL UNIVERSITY Three The CPR shall provide migration from one authorization level to another that is automatic and seamless.

US_00270 FUNCTIONAL UNIVERSITY Three The CPR shall provide a mechanism for students to be able to reset their passwords through all stages of the student lifecycle.

US_00290 FUNCTIONAL UNIVERSITY Three The CPR shall provide central management of password changes, with appropriate customer service for students at a distance.

US_00310 FUNCTIONAL UNIVERSITY Three The CPR shall provide real-time access, verification and updating.

US_00330 FUNCTIONAL UNIVERSITY Two 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 FUNCTIONAL UNIVERSITY Three The CPR shall perform real-time updates of its data that is received from Systems of Record (SoR).

US_00350 FUNCTIONAL UNIVERSITY Three The CPR shall provide reliable and accurate matching.

US_00360 FUNCTIONAL UNIVERSITY One The CPR shall provide a facility to update match-related information, like address history, gender, DOB and name history.

ER_00540 FUNCTIONAL UNIVERSITY Two 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 FUNCTIONAL UNIVERSITY One The CPR shall provide a mechanism to mark a record as a candidate for archival or deletion.

US_00090 FUNCTIONAL UNIVERSITY One The CPR shall record the registration authority that created an identity.

US_00100 FUNCTIONAL UNIVERSITY Three The CPR shall provide interfaces for account management

US_00110 FUNCTIONAL UNIVERSITY Three The CPR shall archive “inactive” users allowing for easy reinstatement for temporary


20

rehires. US_00130 FUNCTIONAL UNIVERSITY Three The CPR shall provide a means to

administer accounts for students at other institutions – for example, student interns from South Hills

US_00001 FUNCTIONAL UNIVERSITY Three The CPR shall distinguish between international and non-international data for matching purposes.

US_00020 FUNCTIONAL UNIVERSITY Three The CPR shall support the storage of multiple appointment data for employees.

US_00030 FUNCTIONAL UNIVERSITY Three The CPR shall provide a notification service for any and/or all changes related to a person’s information.

US_00040 FUNCTIONAL UNIVERSITY Three The CPR shall provide a mechanism to provide services for personnel that have no official affiliation with the University.

US_00050 FUNCTIONAL UNIVERSITY Three The CPR shall provide a facility to easily re-activate an account for a returning student.

US_00060 FUNCTIONAL UNIVERSITY Three 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 FUNCTIONAL UNIVERSITY Three The CPR shall support services that notify stakeholders of a user’s change in status.

US_00060 FUNCTIONAL UNIVERSITY Three The CPR shall support the provisioning of identities for affiliates (like volunteers).

US_00200 FUNCTIONAL UNIVERSITY Three The CPR shall accurately represent the employment status of all Hershey Medical Center employees.

US_00720 FUNCTIONAL UNIVERSITY Three The CPR shall accurately represent the type of a technical service employees contained within its registry.

US_00960 FUNCTIONAL UNIVERSITY Three The CPR shall have an affiliation that represents alumni donor volunteers.

US_00970 FUNCTIONAL UNIVERSITY Three The CPR shall include an affiliation that represents Alumni Association member.


21

US_00730 FUNCTIONAL UNIVERSITY Three The CPR shall provide a means for identifying student interns (so that they can gain access to Human Resource systems.)

US_00720 FUNCTIONAL UNIVERSITY Three The CPR shall maintain an accurate employment status for wage payroll employees. (Currently status is determined by examining last pay date.)

US_00410 FUNCTIONAL UNIVERSITY Three All registration authorities shall require the same data for creating a record at a specified IAP.

US_00750 FUNCTIONAL UNIVERSITY Two The CPR shall provide a linkage between various accounts: student/parent, employee/spouse, employee/dependents

US_00750 FUNCTIONAL UNIVERSITY Two The CPR shall provide a service for delinking various accounts (student/parent,employee/spouse,employee/dependents)

US_00050 FUNCTIONAL UNIVERSITY Three The CPR will reuse the same access id if an individual resumes a relationship with the university after many years.

POL_00100 FUNCTIONAL UNIVERSITY Three The CPR shall require as much data as is needed and allowed by policy to ensure reliable matching of records.

US_00920 FUNCTIONAL UNIVERSITY Three The CPR shall provide a clear indicator that a record has been transferred to a surviving spouse.

US_00080 FUNCTIONAL UNIVERSITY Three The CPR shall flag records that match a SSN in CIDR if other match data is inconsistent for further review.

ER_01010 FUNCTIONAL UNIVERSITY One The CPR shall support the functionality to store a person’s E-mail address.

US_00880 FUNCTIONAL GENERAL Three The CPR shall support the publishing of information to external sources in mixed case.

US_00870 FUNCTIONAL GENERAL Three 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 FUNCTIONAL GENERAL Three The CPR shall provide a mechanism for an individual to request that their non system


22

critical data be expunged from the system.

ER_02060 FUNCTIONAL GENERAL Three 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 FUNCTIONAL EXTERNAL Three 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 FUNCTIONAL EXTERNAL Three THE CPR shall assign a value to eduPersonPrincipalName in the form of formuser@domain.

EXT_00001 FUNCTIONAL EXTERNAL Three THE CPR shall assign a value to givenName.

EXT_00001 FUNCTIONAL EXTERNAL Three The CPR shall assign a value to displayName.

EXT_00001 FUNCTIONAL EXTERNAL Three The CPR shall assign a value to mail.

EXT_00001 FUNCTIONAL EXTERNAL Three The CPR shall populate for people, information in the person, organizationalPerson, and inetOrgPerson objectClasses.

EXT_00010 FUNCTIONAL EXTERNAL Three The CPR shall populate the eduPersonPrimaryAffiliation attribute for entities that have a relationship with the University.

EXT_00020 FUNCTIONAL EXTERNAL Three The eduPersonPrimaryAffiliation values shall be limited to faculty, student, alum, member, affiliate, employee and library-walk-in.

EXT_00030 FUNCTIONAL EXTERNAL Three The CPR shall populate all of a user's affiliations in the eduPersonAffiliation attribute


23

(see eduPersonPrimaryAffilation for a definition of the values).

EXT_00040 FUNCTIONAL EXTERNAL Three The CPR shall populate the eduPersonEntitlement attribute to indicate a user's set of rights to specific resources.

EXT_00050 FUNCTIONAL EXTERNAL Three The CPR shall support the storage of information populated in the eduPersonNickname attribute.

EXT_00060 FUNCTIONAL EXTERNAL Three 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 FUNCTIONAL EXTERNAL Three 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 FUNCTIONAL EXTERNAL Three 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 FUNCTIONAL EXTERNAL Three 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 FUNCTIONAL EXTERNAL Three The CPR shall provide controls on access and changes to critical data

EXT_00230 FUNCTIONAL EXTERNAL Three 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 FUNCTIONAL EXTERNAL Three Shared secret shall have at least 10 bits of min-entropy to protect against an untargeted attack.


24

EXT_00150 FUNCTIONAL EXTERNAL Three The CPR shall provide detect and mitigate a suspected or attempted credential compromise.

US_00990 FUNCTIONAL USE CASE Three The system shall have the capability for providing access to services and programs for accepted freshmen in the semester before classes begin.

US_00990 FUNCTIONAL USE CASE Three The system shall have the capability of establishing identities for prospective students at first contact with the university.

US_01000 FUNCTIONAL USE CASE Three 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 FUNCTIONAL USE CASE Three 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, email for recruiting purposes)

US_00130 FUNCTIONAL USE CASE Three The system shall be able to provide services to individuals working as either paid or unpaid interns at the university.

US_01010 FUNCTIONAL USE CASE Three 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 FUNCTIONAL USE CASE Three 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.


25

POL_00200 FUNCTIONAL USE CASE Three 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.


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.

FUNCTIONAL USE CASE Three CPR shall provide a proxy for supervisor of sponsored accounts.

NR_00720 NON-FUNCTIONAL

Three The CPR shall limit the possibility of creating multiple records for all levels of assurance.


Three The CPR shall provide a process for changing the default password policy for individual records.


Three The CPR shall be able to adapt to any new university policies.


EXISTING REGISTRY

Three The CPR shall provide a feature-rich set of web services to enable interaction with its data store.


EXISTING REGISTRY

Three The system shall not contain department specific data elements.


REGS & LEGS Three A data steward shall be assigned to each data element in the CPR.


REGS & LEGS Three The CPR shall include protection for privacy of information.


REGS & LEGS Three The CPR shall define/implement a Data retention policy for Web Server Logs that adheres to University and external policies.


REGS & LEGS Three The CPR shall define/implement a Data retention policy for Web Session Logs that adheres to University and external policies.

NR_00460 NON- REGS & LEGS Three The system shall adequately


27

FUNCTIONAL protect the privacy and integrity of data when transmitted on communication channels.


REGS & LEGS Three 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.


REGS & LEGS Three 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.


REGS & LEGS Three 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.


REGS & LEGS Three Taking reasonable precautions, including personal password maintenance and file protection measures, to prevent unauthorized use of their accounts, programs or data by others.


UNIVERSITY Two There shall be a single central person registry for all registration processes within the University.


UNIVERSITY Three The official data sources (systems of record) for the systems data elements shall be defined.


UNIVERSITY Three There shall be continuity of operations during the transition from old repositories to the new system.


UNIVERSITY Three The system shall have a set of metrics and standards with which to assess performance and efficacy.


28


UNIVERSITY Three The CPR will be a complete and up-to-date person record for each individual University member or affiliate.


UNIVERSITY Three The CPR services will be available to application providers for the real-time provisioning of access.


UNIVERSITY Three The system data elements shall be updated from authoritative sources


UNIVERSITY Three The system shall have a well-defined communications stream for provisioning/deprovisioning.


UNIVERSITY Three The system shall support multiple factor authentication technologies.


UNIVERSITY Three The system shall have a data retention policy consistent with archival policies of the university.


UNIVERSITY Three The system shall have a streamlined "code red" de-provisioning process.


UNIVERSITY Three The system shall be able to provide a digital credential within two hours.


UNIVERSITY Three The CPR shall ensure that identity data remain within the canonical source and not maintain additional data sets with the same data.


GENERAL Three The CPR shall be open, extensible and scalable.


GENERAL Three The CPR shall handle all errors by reporting appropriate responses to the end user and an internal log.


GENERAL Three The CPR shall provide a database to store information about users.


GENERAL Three The CPR shall provide a feature-rich set of web services to enable interaction with its data store.


GENERAL Three The CPR shall be highly available 24/7/365.


GENERAL Three The CPR shall be redundant by having a copy of its data store at an off-site location.


GENERAL Three The CPR shall limit non-emergency outages to the ITS "maintenance window".


29


GENERAL Three The CPR shall provide fault tolerant features to include: mirrored file systems, file system backups and database backups.


GENERAL Three The CPR shall adhere to FERPA, HIPAA, and COPPA regulations in the area of data collection and retention.


GENERAL Three The CPR shall be backed up at the file system and database levels.


GENERAL Three The CPR machine(s) shall only run the necessary services for its operation.


GENERAL Three The CPR system and database administrators shall maintain the physical security of the network and the server hardware.


GENERAL Three 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 Three The CPR administrators shall monitor the security of the server, checking logs, running appropriate security tools, etc.


GENERAL Three 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 Three The CPR administrators shall ensure that the CPR server has the latest software patches and fixes.


GENERAL Three The CPR database shall support international character sets.


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


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

21 Physicians at the Hershey Medical Center and Access to Library Resources

22 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


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


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