This page contains information about some of the attributes in the Harvard identity provider that are available to SAML/Shibboleth applications. Developers can request that attributes about Harvard users be released to their applications (based on business needs) when they apply to register their applications for SAML/Shibboleth SP authentication, and these requests will be evaluated on a case-by-case basis. See below for commonly requested attributes; additionally, please note that other attributes may be available based upon business need. Application developers should feel free to request additional attributes when submitting for application registration.
At Harvard and elsewhere, many earlier authentication systems only handled a single "identifier" for a user — in Harvard's case, examples of identifiers include the HUID, eCommons ID, Advance (Alumni) ID, and XID. However, modern authentication systems also incorporate other properties about a user (such as affiliation) in the information they are able to return.
With this in mind, it can be helpful to consider the difference between an identifier and an attribute when determining what information about users that an application may need. An identifier ideally refers to a single unique user. Some attributes, such as affiliation, have values (such as staff, student, or faculty) that apply to many users. That said, attributes such as email address are sometimes used as identifiers — so the difference may not always be clear.
All requests for attributes except for eduPersonPrincipalName (EPPN) go through an approval process, and those requesting attributes must provide a business rationale for requesting each attribute. For that reason, consider not requesting personally identifiable attributes unless they are strictly necessary to your application or service.
Commonly Used Attributes from the InCommon Standard Set
IAM databases hold a large number of attributes about each user; however, for consistency and standardization, application managers and developers are encouraged to use the standard set of attributes recommended by InCommon. Attributes from the standard set that are currently supported at Harvard are listed below; however, please note that these attributes are available only for users who have HUIDs.
- eduPersonPrincipalName (EPPN): A unique but opaque identifier for a user; this value will never be reassigned to another user. Application managers and developers are encouraged to use EPPN instead of HUID as a user's unique identifier.
- eduPersonScopedAffiliation: One or more of the following values: faculty, staff, student, affiliate, and member. Please see the eduPerson Object Class Specification, published by Internet2, for definitions of these values.
- sn: Surname, also known as last name or family name. A single string value.
- givenName: Also known as first name. A single string value containing the part of the user's name that is not their surname or middle name.
- mail: Email address of record in the Harvard IdDB. Note that this could be an address not ending in harvard.edu.
- displayName: A single string value indicating a person's preferred name, to be used for display purposes such as a greeting or directory listing.
In addition to the commonly used InCommon-standard attributes above, service providers can also request the release of any attributes available within HU-LDAP; however, please note that approval is subject to verified business need, and there may be delays in approval and setup if an attribute has not been previously released to other applications. Application developers should feel free to request additional attributes when submitting for application registration. (For example, an application needing UUID may wish to request the release of eduPersonUniqueID — a long-lived, non-reassignable, omnidirectional identifier suitable for use as a principal identifier by authentication providers or as a unique external key by applications.)
Source: Marlena Erdos