Looking for what constitutes InCommon "Member of Community" status among Harvard users? Please see "About InCommon's 'Member of Community' Status" below — and for a greater level of detail, view our page on IDDB and LDAP Specifics Determining InCommon "Member of Community" Status.

Harvard University's Shibboleth identity provider (IdP) is an identity information service that sends information to applications about users who try to access those applications. The information — contained in a digitally signed message from Harvard — allows an app to make an access control decision without having to "log in" the user directly. Instead, users log in to their home institution — in this case, Harvard.

Our IdP allows Harvard Community users to access applications hosted by other members of the InCommon Federation, a consortium of US-based higher education institutions that support federated login. Applications still have their own individual access requirements — meaning that not every InCommon member application will automatically allow access to everyone with Harvard credentials — but, for users who do meet access criteria for an particular application, the need to establish a separate username and password for that app is eliminated, greatly boosting overall convenience. App owners also benefit by no longer having to maintain name/password databases or manage "I forgot my password" requests.

For more information about Shibboleth and SAML, see Shibboleth/SAML: Info & Flows and Brief Guide to Shibboleth Flows.

About Assertions and ID Proofing

Harvard has a wide variety of users with varying degrees of attachment to the University. The Harvard IdP provides assertions to InCommon-affiliated service providers (SPs) only for those users who have a current Harvard affiliation and have, in most cases, undergone identity proofing. This is because an assertion is, in effect, a promise that Harvard knows who the user is, and we cannot make that promise without significant assurance ourselves that the person is who they claim to be.

ID Proofing and You

For most users, identity proofing happens when they present a government-issued photo ID in order to pick up their Harvard ID card. However, paid University employees who haven't been issued a Harvard ID also go through identity proofing as part of the paperwork required by the U.S. government during the hiring process. (Long-term paid employees who may have been hired before mandated federal identity proofing are also considered ID-proofed by virtue of continuing to receive federal tax forms associated with their Harvard roles.) Emeriti faculty and Harvard Management Company employees are also considered to be identity-proofed.

Please note that students who have not undergone identity proofing — most notably Harvard Extension School students — do not receive an assertion from the Harvard IdP when trying to access InCommon-affiliated sites.

How the IdP Checks For ID Proofing

At present, Harvard's IdP checks whether or not a user's attributes indicate that an ID card has been produced. If not, the IdP proceeds to check whether the user is a paid employee, emeritus faculty, or a Harvard Management Company employee.

About InCommon's "Member of Community" Status

The eduPerson status "Member of Community" is used by some InCommon-affiliated external SPs (such as HathiTrust) to grant access to users. InCommon rules require Harvard to limit "member" status to users who receive the "basic set of institutional privileges" that is granted to (full-time) faculty, staff, and students, as well as those who may not strictly fit into these categories but are still "eligible for the full set of institutional privileges. " Further details can be found in the Internet2 specification for the eduPerson object class, which InCommon itself references.

Note that "member" status does not affect a user's access to any internal Harvard resources, including cloud services run by vendors with whom Harvard has a close relationship (such as ServiceNow.) "Member" is pertinent only for a small number of external service providers that choose to grant access based upon this status.

Harvard's user population includes a wide variety of roles, and the policy is thus a bit complex. Common roles granted member status include:

• All full-time paid employees, including faculty
• Currently enrolled students
• Students studying abroad or on leave, but paying a facilities fee
• DCE students (however, as indicated above, they may not have access to InCommon resources due to not having been ID proofed)
• Harvard Management Company employees
• Harvard Board of Overseers personnel
• Some long-term "temporary" staff (these users have a particular job code distinguishing them from other temporary staff)

For full details, please see our page on IDDB and LDAP Specifics Determining "Member of Community" Status.

IdP FAQs for Support Staff

Help-desk and other Harvard IT support staff can view our Harvard IdP: Support for Support page for answers to common user issues surrounding Harvard's IdP, including information on when users should be referred to third-party institutions and when internal tickets should be opened.

IdP FAQs for End Users

What's the point of the Harvard IdP?

Our IdP allows Harvard Community users to access applications hosted by other members of the InCommon Federation, a consortium of US-based higher education institutions that support federated login. Applications still have their own individual access requirements — meaning that not every InCommon member application will automatically allow access to everyone with Harvard credentials — but, for users who do meet access criteria for an particular application, the need to establish a separate username and password for that app is eliminated, greatly boosting overall convenience.

What is an Identity Provider (IdP)?

Harvard's IdP is a service that sends information to an app about a user trying to access the app. This information – formatted as an XML document called a SAML assertion – allows the app to make an access control decision without having to log in the user directly. Instead, the user logs in to his or her home institution – in this case, Harvard. We use the Shibboleth Identity Provider service; you can learn more about it here.

What is a Service Provider?

"Service Provider" has multiple related meanings: At times it simply refers to the InCommon-provided code that serves as a proxy in front of an app to implement the SAML messages, formats and flows (collectively known as "SAML protocol"), as well as attribute handling on behalf of the app. Sometimes the term is used to mean the app itself.  And sometimes it's used to refer to something (other than the InCommon code) that serves as a proxy implementing SAML protocol. You may want to learn more here.

What is Shibboleth?

Shibboleth, an open source project, is one of the world's most widely deployed federated identity solutions. InCommon uses Shibboleth software to implement its SAML identity federation protocol, in addition to implementing rich facilities for managing user attributes that may help service providers make authorization decisions.

What is SAML?

Developed by the Security Services Technical Committee of OASIS, the Security Assertion Markup Language (SAML) is an XML-based framework for communicating information about a user, along with a set of message flows for requesting user information and responding to those requests.

What is a 'SAML assertion'?

A SAML assertion is an XML document containing information about a user's identity and/or attributes. It can be thought of as a transportable form of a user's directory entry — that said, Harvard is very careful about the potential sensitivity of the information (attributes) released in our IdP's SAML assertions about users.

Why can't I access the federated site I'm trying to log in to?

You may not be eligible for an assertion from Harvard (see above for details on University assertion policy), or you may not meet that site's specific access requirements; even if there is nothing blocking you from successful assertion by the Harvard IdP, every third-party site has its own access rules, and may not let you in as a result. You may wish to contact technical support for the site you're trying to reach, or even search for the site name and "Shibboleth" in a search engine to learn more about access requirements; third-party sites, including the DMP Tool and HathiTrust, often publish their access rules online.

Please note that if you place a FERPA block on your records, the Harvard IdP will not be able to issue you an assertion to InCommon-affiliated sites.

If you still feel that the problem is on the Harvard side, please contact the HUIT Help Desk, and provide both the URL that you entered and the URL at which you ended. 

The site I want to get to is asking me to choose from a list of institutions including "Harvard" and "Harvard Business School," but not my school. What do I do?

Choose "Harvard." You'll then be redirected to a Harvard-based authentication system and asked to login.

What's an EPPN?

EPPN is a shorthand for eduPersonPrincipalName, an attribute defined in the Internet2 eduPerson object class specification that is intended to uniquely identify a user at a given institution. At Harvard, we create an EPPN for each user by transforming a long "opaque internal identifier" into a shorter opaque identifier and then adding on "@harvard.edu" —  for example,  4A2849CF119852@harvard.edu.Your EPPN remains the same even if you change your name — making it, in identity management terminology, unique and persistent.

What's eduPerson?

Informally, eduPerson is a collection of attributes relevant to users in higher education. These attributes can help an application perform access control on the user as well as personalization for the user. You can see the full specification for eduPerson here; however, InCommon recommends the use of only a small subset of the large set of eduPerson attributes in its attribute summary.

Source: Marlena Erdos