This page is intended for Harvard Help Desk employees attempting to solve user access problems involving the Harvard identity provider (IdP). Most commonly, users will be attempting to access an external site such as HathiTrust and not be able to gain access.

How a Typical Access Flow Works

• User tries to reach a URL on the site or application of interest
• User may be asked "where are you from?" (WAYF) and prompted to select their home institution from a list
• If the user selects "Harvard University" or "Harvard Business School," he or she will be redirected to the HarvardKey login screen and prompted to log in (if a cookie is not already valid)
• If the user meets the site's authorization requirements, he/she gains access — but note that, as with other protected Harvard apps, just because a user can log in doesn't necessarily mean access is granted

When Can We Help?

Harvard users will use their credentials to access a variety of types of sites/applications:  

• Internal Harvard-only
• InCommon Federation sites (generally external to Harvard)
• Sponsored vendor sites (vendor is in partnership with a sponsoring Harvard department)

With respect to how we can help the user, we have Harvard business and technical contact info for Harvard-only sites and sponsored vendor sites. We do not necessarily or easily have contact details for InCommon sites.

Common User Issues

User sees a "can't connect" or "resource not available" message

In this case, the IdP or one of the HUIT services it relies on may be down — or the application the user is trying to access is down. Please check for incident announcements, and follow your typical protocol for major incidents.

If there are no major incidents on record, try to determine if the problem is with the application the user is trying to reach. If the problem is a new issue on the HUIT side (and not the application side), please create a ticket.

If the application is down and it is either internal to Harvard or sponsored by a Harvard department, contact the Harvard business or technical owner. If the app is not internal to Harvard, there is little we can do. The IdP technical team may have contact info for the app owner, but unless the issue is major, this might not be appropriate to escalate to a Harvard IdP team.

User fails to log in correctly

With the advent of one-way federation, the user's authentication source may be HarvardKey (AuthLDAP), but could also be HMS eCommons, a HUIT AD, or possibly the HLS or HBS authentication systems. Please see documentation for one-way federation if you think this is the case. Otherwise, please follow the standard procedures for addressing login problems.

User logs in but sees an "unauthorized" message

The user probably doesn't have the attributes required for access. Collect the URL the user is trying to reach. If the site is listed under "Sites and Access Requirements" at the bottom of this page, you may find information to help inform the user why he or she is unable to access the site. However, since we do not control authorization rules for external sites, we generally are unable to offer help.

User goes to a site whose "Where Are You From?" list doesn't include Harvard 

Collect the URL the user is trying to reach and details regarding what the user is trying to do at the site. Pass this information, along with the user's HUID and/or login name, on to Directory Services as a ticket.

User receives a "you are ineligible assertion" message

In this case, because of a policy conflict, the IdP cannot provide an assertion for the user, even though the user authenticated with Harvard.

Find the URL the user is trying to reach. If it is external to Harvard, the user is likely ineligible for an assertion because he or she has not been identity proofed. Ask the user if he/she has a currently valid Harvard ID card. If yes, please create a ticket for Directory Services with the user's HUID and indicate that the user has a valid Harvard ID card. If the user doesn't have an ID card but has a current Harvard affiliation, explain that because they have not gone through the identity proofing process involved in obtaining the card, they cannot use their Harvard credentials to gain access. 

If the URL is internal to Harvard, create a ticket for Directory Services listing the URL, the user's HUID (if it exists), and/or their login name. Note in the ticket that the user couldn't get assertion for a Harvard SP.

User sees "An error occurred while processing your request"

Find out what URL the user is trying to reach. Sent a ticket to Directory Services with that URL.

Vendor claims a Harvard need for its service/product

Tell the vendor that only a Harvard faculty or staff member can request the addition of new third-party products or services. Once a faculty or staff member requests that a new app be added, Directory Services will work with the department to assess the business need and work with the vendor if appropriate. If the vendor asks how they establish interest within a Harvard department, please tell them to use their own marketing and sales channels. Note that a product being available free of charge has no effect on this policy; it isn't "free" for Harvard to onboard and maintain a vendor and maintain them, nor to service help desk calls related to their product.

User winds up at no.saml1.sso.url.defined.com after choosing "Harvard"

If a user goes to a site that uses an old version of the SAML authentication protocol and that site is using the InCommon Discovery (WAYF) service, the user will get redirected to the fitness site "defined.com." For reference, the error screen is depicted below.

Please find out what URL the user is trying to reach, and send a ticket to Directory Services with that URL.

Other Errors

If the user's problem doesn't fall into the above list, get the URL the user initially tried to reach and note it as the "initial URL." Then note the URL the user wound up on as the "final URL", as well as any message the user saw on that final URL page. The message may tell you immediately what's wrong; if not, the URLs you note may provide good clues as to what went awry.

If you are unable to diagnose the problem from the message the user saw, take a closer look at the final URL. If it's a HarvardKey site (e.g. a site beginning in https://key.iam.harvard.edu), then the user probably failed to log in correctly.

If this isn't the case, find the domain name in the final URL to see if the site is a Harvard application or a third-party InCommon member site. To see if the site is a member of InCommon, check their current list of service providers. If you can't find the site, it's unlikely that the user's interaction with the site traversed the Harvard IdP. Please ask the user what they were doing and how they tried to log in. At this point, the initial URL comes in handy: Try it yourself to see if you can replicate the user's actions. Hopefully, this will provide some helpful info. (Please note that if the user is trying to access a site that isn't part of InCommon or a Shibboleth-enabled Harvard vendor, there's little you can do to help.) If a problem still remains, send a ticket to Directory Services with the initial and final URLs, the user's HUID and/or login name, and any other information that may be of help.

Sites and Access Requirements

Below is a list of often-requested sites and the attributes the user must have to access each. Attributes are name/value pairs, just like the attributes stored in LDAP (e.g. email=sample@harvard.edu). The Shibboleth IdP sends a set of attributes about a user to InCommon sites; however, please note that satisfying the attribute requirements listed below may not be enough to grant access. The site may have other requirements for access, including time of day, location, multi-factor authentication, etc.

• HathtiTrust requires that eduPersonScopedAffiliation attribute include the "member" or "alum" value.  Please see member_policy for information on who gets this attribute value. The user may not qualify (example: as of fall 2013, we do not support the "alum attribute").
• DMP Tool requires that we send the eduPersonPrincipalName and email attributes, but does not have requirements about the values of these attributes. If the user is a student, find out if he or she issued a FERPA block, since this would knock out the IdP's ability to send an email address.

Source: Marlena Erdos