Harvard University's enterprise authentication service is known as HarvardKey. The service is available for securing online applications that support University activities including administration, instruction, collaboration and research. To make a request to register an application with HarvardKey, submit this form.
During the interactive authentication process, a user supplies their unique credential (HarvardKey login name and password) in order to access online resources. Users create and manage their HarvardKey credential using the HarvardKey self-service application. All faculty, staff, student and non-employee affiliate users are required by information security policy to use a second factor with their password through the two-step verification service that is integrated with HarvardKey.
HarvardKey authentication services are available for web applications with two standard protocols: CAS and SAML 2.0. Both of these protocols support single sign-on (SSO), relieving users of the need to enter their HarvardKey credential each time they access a different web application. Application owners can decide whether to allow single sign-on to their applications. Unless there are security reasons to force a direct login, applications will typically take advantage of SSO to simplify access for their users.
The HarvardKey system replaced the proprietary system (known as the PIN system) with the open-source Jasig Central Authentication Service (CAS) in 2015. However this replacement was extended with a PIN2/CAS protocol bridge which acts as a protocol adapter. This bridge supports the legacy PIN2 protocol while leveraging CAS for authentication and single sign-on. There is also an option to integrate with a Shibboleth-based Identity Provider (IdP) for the SAML 2.0 protocol. The HarvardKey IdP is integrated with the InCommon Federation. Both protocols are integrated to provide seamless single sign-on for HarvardKey users, regardless of which protocol is being used. The PIN2 protocol is still supported for a small set of legacy applications; however, the protocol has been deprecated.
The diagram below displays the system's current state:
HarvardKey Authentication using LDAP or AD
By policy, web applications that integrate with HarvardKey must use either the CAS or SAML 2.0 protocol. Applicationsare prohibited from handling the user credentials directly. However, applications that require direct integration with a directory (v3 LDAP protocol) may request evaluation for integration with HarvardKey credentials using the HarvardKey LDAP or the University Active Directory. Security requirements pertain.
Authentication vs. AuthorizationAuthentication services provide user authentication, but not user authorization. This distinction is important. Authentication verifies that a user is who they say they are, but it cannot confirm whether the user should have access to a particular application.
After authentication comes authorization — the process determining whether the user is granted access to areas within an application.
It is important to note that simply authenticating a user with HarvardKey does not provide appropriate authorization for University-managed applications and services. The HarvardKey credential does not expire at the end of an individual user’s active affiliation. This continuation is in place so that applications can implement authorization rules aligning with their policies. Some applications continue to allow access after the user's actual end date for active affiliation.
Implementing authorization for a HarvardKey protected application can be done in a variety of ways (in either protocol):
-
Attributes about the authenticated user are eligible to be sent as part of the authentication response in a process called assertion. The application can then use these attributes to decide about access.
- The most commonly used attribute for authorization is group membership expressed as the ‘IsMemberOf’ attribute.
- Alternatively, an application can query for user attributes from an attribute repository such as LDAP or the enterprise Group Service (Grouper). Access to query for attributes is subject to an approval process.
-
An authorization filter can be applied using an application authorization group to filter the authentication response based on whether the user is a member of a specified group.
- Authorization filter design typically involves a consultation with an IAM specialist and may also be subject to an approval process.
- If necessary, authorization may be delegated entirely to the local application. The authentication response from HarvardKey will convey a unique user identifier which must be mapped to application-specific permissions that are in the exclusive control of the relying application.
You may find that both CAS and SAML 2.0 are suitable for your application. If that is the case, the determining factors will include the environment of your application (operating system, web server, application server, etc.), software frameworks, and the programming language that your app uses.
For example:
SAML 2.0 integration involves installing a service provider (SP) software package that sits inside your web server, isolated from the application. This package delivers authentication and attribute information to the application using the web server’s environment variable or custom HTTP headers.
CAS offers additional integration options via software packages known as CAS clients; these can provide SAML SP-like integration options, APIs, or libraries for integration that can be used directly within your application.
Please get in touch with the IAM team if you have further questions via mailto: iam@harvard.edu