InCommon Participant Operational Practices

As a requirement of Harvard's participation as an identity provider (IdP) and various Harvard units' participation as service providers (SPs) in the InCommon identity management federation, please find below answers to InCommon's questions as laid out in the InCommon Federation Participant Operational Practices.

Parties interested in registering as a SP under Harvard's InCommon membership should consult these instructions for how to get started.

 

Federation Participant Information

1.1 Organization Name and Date
The InCommon Participant Operational Practices information below is for Harvard University.
Harvard IdP information was last revised on November 14, 2013.
Digital Dictionary of American Regional English/Digital Loeb Classical Library SP information was last revised on August 4, 2014.

1.2 Identity Management and/or Privacy Information
Additional information about the Participant's identity management practices and/or privacy policy regarding personal information can be found online at the following locations:
Harvard University: http://security.harvard.edu
Digital Dictionary of American Regional English: http://www.daredictionary.com/page/privacy/
Digital Loeb Classical Library (policy will go live concurrent with site launch in mid-September 2014): http://www.loebclassics.com/page/privacy/

1.3 Contact Information
The following offices can answer questions about the Participant's identity management system or resource access management policy or practice:

For IdP-related questions:
Name: IdP Support Team
Title or role: IdP Support
Email: IdP_Support@harvard.edu
Phone: 617.495.7777

For SP-related questions:
Name: Harvard University Press Digital Support
Title or role: Digital Support
Email: digitalsupport_hup@harvard.edu

Identity Provider Information

Community

2.1 If you are an identity provider, how do you define the set of people who are eligible to receive an electronic identity? If exceptions to this definition are allowed, who must approve such an exception?

The Harvard IdP provides assertions only for persons with a current affiliation with the University.

2.2 "Member of Community" is an assertion that might be offered to enable access to resources made available to individuals who participate in the primary mission of the university or organization. For example, this assertion might apply to anyone whose affiliation is "current student, faculty, or staff." What subset of persons registered in your identity management system would you identify as a "Member of Community" in Shibboleth identity assertions to other InCommon participants?

The Harvard IdP will assert "Member of Community" for faculty, active students, and staff, where staff includes both employees and contract workers.

Electronic Identity Credentials

2.3 Please describe in general terms the administrative process used to establish an electronic identity that results in a record for that person being created in your electronic identity database. Please identify the office(s) of record for this purpose. For example, "Registrar's Office for students; HR for faculty and staff."

Before assigning electronic identities, Harvard's HR personnel on-board faculty and staff using normal U.S. new-hire processes, and Harvard's registrars on-board students following processes common to higher education in the U.S.

2.4 What technologies are used for your electronic identity credentials (e.g., Kerberos, userID/password, PKI ...) that are relevant to Federation activities? If more than one type of electronic credential is issued, how is it determined who receives which type? If multiple credentials are linked, how is this managed (e.g., anyone with a Kerberos credential also can acquire a PKI credential) and recorded?

Most users have User ID/password credentials in at least two back-end identity repositories – an LDAP-based repository for access to web-based resources, and one or more Active Directory repositories. The identity system involved in federation allows users to authenticate with either set of credentials. A user's multiple accounts (LDAP and Active Directory) are linked via the internal Harvard identifier the user received upon on-boarding.

2.5 If your electronic identity credentials require the use of a secret password or PIN, and there are circumstances in which that secret would be transmitted across a network without being protected by encryption (i.e., "clear text passwords" are used when accessing campus services), please identify who in your organization can discuss with any other participant concerns that this might raise for them:

In general, passwords are not transmitted in the clear, however this is not true 100% of the time. Harvard is taking steps to rectify this situation. Also, passwords within a secured data center that stay within that data center are sometimes transferred in the clear.

2.6 If you support a "single sign-on" (SSO) or similar campus-wide system to allow a single user authentication action to serve multiple applications, and you will make use of this to authenticate people for InCommon service providers, please describe the key security aspects of your SSO system, including whether session timeouts are enforced by the system, whether user-initiated session termination is supported, and how use with "public access sites" is protected.

The SSO system behind the IdP enforces a statically specified timeout value for all users making use of federation to external SPs. Further, the user's session ends when the user closes his or her browser. The SSO system also provides the ability for a user to "log out." An application can force explicit re-authentication of a user as a means of protecting itself from taken-over sessions at public access sites.

2.7 Are your primary electronic identifiers for people, such as "net ID," eduPersonPrincipalName, or eduPersonTargetedID, considered to be unique for all time to the individual to whom they are assigned? If not, what is your policy for re-assignment and is there a hiatus between such reuse?

eduPersonPrincipalName and eduPersonTargetedID are unique for all time and are never reassigned. A user's internal identifier is never reassigned and is also not released by the IdP.

Electronic Identity Database

2.8 How is information in your electronic identity database acquired and updated? Are specific offices designated by your administration to perform this function? Are individuals allowed to update their own information online?

HR and registrars perform the initial collection of demographic information, as stated above. Faculty and staff who can authenticate with the SSO system may update some of their own information — for example, mailing address but not name — online. Some Schools allow students to make updates to demographic information. Harvard also has an administrative team dedicated to identity management that can make changes to a user's information if necessary.

2.9 What information in this database is considered "public information" and would be provided to any interested party?

Information about faculty and staff is governed by the access policies of the School and department in which the user works. For students, Harvard defines "directory information" as releasable under FERPA, here. However, the attributes listed may be subject to further access controls designated either by the student or by administrators at the student's School of enrollment.

Uses of Your Electronic Identity Credential System

2.10 Please identify typical classes of applications for which your electronic identity credentials are used within your own organization.

HR functions, learning management systems, Active Directory-enabled applications, and access to library resources.

Attribute Assertions

2.11 Would you consider your attribute assertions to be reliable enough to:

  • Control access to on-line information databases licensed to your organization? Yes.
  • Be used to purchase goods or services for your organization? Yes.
  • Enable access to personal information such as student loan status? Yes.

Privacy Policy

2.12 What restrictions do you place on the use of attribute information that you might provide to other Federation participants?

Information must be used only for the purpose for which it has been provided. It must not be aggregated and also must not be revealed to third parties without Harvard's permission.

2.13 What policies govern the use of attribute information that you might release to other Federation participants? For example, is some information subject to FERPA or HIPAA restrictions?

All attribute release is subject to review by the administrative personnel responsible for the IdP, and takes into consideration FERPA rules as well as other policy considerations. We do not expect to be dealing with data subject to HIPAA restrictions.

Service Provider Information

3.1 What attribute information about an individual do you require in order to manage access to resources you make available to other Participants? Describe separately for each resource ProviderID that you have registered.

The following applies only the Digital Dictionary of American Regional English (www.daredictionary.com), hereafter referred to as DARE, and the Digital Loeb Classical Library (www.loebclassics.com), hereafter referred to as Loeb: We require that a user have the "member” value in the 
eduPersonScopedAffiliation attribute. An additional requirement is that
 the user's institution be registered with Harvard University Press and have either paid an access fee or be within the time period of an official free trial. Users also are able — but not required — to create personal accounts for generating and storing personal content such as annotations. For creation of personal accounts, we require a full name, email address, and self-selected password, all to be entered by the user rather than transmitted via the Identity Provider.  

3.2 What use do you make of attribute information that you receive in addition to basic access control decisions? For example, do you aggregate session access records or records of specific information accessed based on attribute information, or make attribute information available to partner organizations, etc.?

DARE and Loeb only: We do not make attribute information available to any partner organizations. We do aggregate anonymous usage statistics at the IdP level, which is accessible to IdP administrators. We also log metadata on platform content saved by users who have opted to create personal accounts (which, as noted above, rely on user-entered information and no IdP-provided attribute assertions beyond the eduPersonScopedAffiliation attribute).

3.3 What human and technical controls are in place on access to and use of attribute information that might refer to only one specific person (i.e., personally identifiable information)? For example, is this information encrypted?

DARE and Loeb only: For the majority of site users, we will neither collect nor store any personally identifiable information whatsoever. When users create optional personal accounts, we collect and store their name, email address, and a user-generated password, which the user may independently reset at any point. Stored passwords are encrypted. Databases and servers are secured and updated as appropriate. Note that DARE and Loeb are both built on PubFactory, an online publishing platform from Safari Books Online. Only Harvard University Press and Safari Books Online employees with reason to access user information are granted such access. Employees must authenticate with individual credentials before accessing customer data.

3.4 Describe the human and technical controls that are in place on the management of super-user and other privileged accounts that might have the authority to grant access to personally identifiable information?

DARE and Loeb only: At Harvard University Press, there is a six-month review of accounts plus a standard entry/exit access review for all accounts created or removed. Safari Books Online uses administrative, technical, and physical safeguards to protect the security, confidentiality, and integrity of personally identifying information against loss, misuse, unauthorized access, disclosure, alteration, and destruction. Safari Books Online also complies with the U.S.-E.U. Safe Harbor framework and the U.S.-Swiss Safe Harbor framework as set forth by the U.S. Department of Commerce regarding the collection, use, and retention of personal data from European Union member countries and Switzerland. Safari Books Online, LLC has certified that it adheres to the Safe Harbor Privacy Principles of notice, choice, onward transfer, security, data integrity, access, and enforcement. To learn more about the Safe Harbor program, and to view Safari Books Online, LLC's certification, please visit http://www.export.gov/safeharbor

3.5 If personally identifiable information is compromised, what actions do you take to notify potentially affected individuals?

DARE and Loeb only: Safari Books Online has internal policies in place with respect to the detection, investigation, and remediation of data breaches, and also with respect to communications with stakeholders (affected users and customers) and legal compliance in the event of a data breach. Such policies cover Harvard University Press as well.

Other Information

4.1 Identify the version of Internet2 Shibboleth code release that you are using or, if not using the standard Shibboleth code, what version(s) of SAML and SOAP and any other relevant standards you have implemented for this purpose.

We use IdP 2.4.

4.2 Are there any other considerations or information that you wish to make known to other Federation participants with whom you might interoperate? For example, are there concerns about the use of cleartext passwords or responsibilities in case of a security breach involving identity information you may have provided?

All SPs that receive identifiable information about students are considered university agents and must agree that they are covered by FERPA. We require that we be notified promptly of any situation that could put information about identifiable people at risk. Please contact IdP_Support@harvard.edu or 617.495.7777 to report a breach that might affect Harvard users.