About HarvardKey Authentication Services
Harvard University's enterprise level authentication service is known as HarvardKey. The service is available to University IT service providers for securing online applications that support University activities including administration, instruction, collaboration and research.
During the interactive authentication process, a user supplies a unique login name (HarvardKey) 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 add a second factor to their password through the two-step verification service that is integrated with HarvardKey.
HarvardKey authentication services are available for web applications in two protocol standards: CAS and SAML 2.0. Both of these protocols support University-wide single sign-on (SSO) service, relieving users of the need to enter usernames and passwords each time they access a different web application. Application owners 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 this auto-login to simplify access by eliminating the need to input the password as often.
HarvardKey system replaced the proprietary system (known as the PIN system) with the open-source Jasig Central Authentication Service (CAS) 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 IdP for the SAML protocol. The IdP is integrated with the InCommon Federation. All protocols are integrated to provide a seamless single sign-on experience for HarvardKey users, regardless of which protocol specific applications are using. At this writing, the PIN2 protocol is still supported for a small set of existing applications; however, the protocol will be discontinued soon. Many applications have migrated to CAS or SAML to take advantage of additional authorization services that are only available with these two protocols.
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 the CAS or SAML protocol and are 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 instance or the University Active Directory instance. Security requirements pertain.Authentication vs. Authorization
Authentication 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.
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/current affiliation. This is done so that applications can implement authorization policies that align with their policies which sometimes allow access after the affiliation end date.
Implementing authorization for a HarvardKey protected application can be done in a variety of ways:
Attributes about the authenticated user are eligible to be released as part of the authentication response in a process called assertion. The application can then use these attributes to decide about access.
- Assertion can be used with both the CAS and SAML authentication protocols. Access to attributes is subject to an approval process.
- 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 Group Service. Access to 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 the specified group.
- Authorization filtering can be used with both CAS and SAML protocols
- Authorization filter design typically involves a consultation with an IAM specialist and may 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 are suitable for your application. If that is the case, the determining factors will include the environment (operating system, web server, application server, etc.), software frameworks, and programming language that your app uses.
SAML 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.