About Harvard's Authentication System
The Harvard authentication system, HarvardKey, is a service that authenticates users of online applications created by or affiliated with Harvard. The authentication process verifies users' identities in order to allow them to access applications; to do this, the user provides a unique login name and confirms that identity with the authentication service by sending the login name's correct password. The system then matches the username and password provided with data stored in a directory server, usually LDAP or Active Directory.
HarvardKey also offers application owners the option to participate in a 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. Participation in the SSO service is determined by each application owner, and is not required by HUIT, but it can make the user's overall experience significantly easier.
When attempting to authenticate a user, a user agent — the application being accessed — and Harvard's authentication system communicate via a defined sequence of messages known as an authentication protocol. In 2013, the IAM program made significant enhancements to the authentication system to support a growing number of commonly used authentication protocols as well as improve the overall infrastructure. One of the most significant enhancements was to replace Harvard's proprietary system (PIN2) with the open-source Jasig Central Authentication Service (CAS), a more commonly accepted authentication protocol. IAM extended CAS to support all former PIN2 features, and migration to CAS was transparent to all PIN2 applications due to IAM implmenting a PIN2/CAS protocol bridge to act as a protocol adapter. This bridge supports the PIN2 protocol while leveraging CAS for authentication and single sign-on. In late 2013, HUIT deployed a Shibboleth-based IdP and integrated it with Harvard's authentication system, in the process adding support for the SAML protocol.
At present, authentication at Harvard supports the CAS and SAML protocols, though some applications using PIN2 also remain. These protocols seamlessly integrate into the single sign-on option provided by the enhanced Harvard authentication system. The diagram below displays the system's current state:
Authentication vs. Authorization
The Harvard authentication system provides 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 or not the user should have access to a particular application. After authentication comes authorization — the process determining whether the user is actually granted access to areas within an application.
Implementing authorization for an application can be done in a variety of ways, and the authentication protocol being used can also dictate the choice of authorization method. Here are the details:
Authorization can rest entirely within the local application, just relying on the given identifier. This approach is an option with all authentication protocols offered.
After authentication, an application can query for user attributes from different available sources — including HU-LDAP — and those attributes can be used to make an access decision. This approach is also an option with all authentication protocols offered.
Attributes about an authenticated user can be released as part of the authentication response in a process called assertion. The application can then use these attributes to make a decision about access. Assertion can be used with both the CAS and SAML authentication protocols.
Choosing an Authentication Protocol
So which protocol is the best choice for your application? See below for a flowchart and protocol comparison chart that may help you make a decision.
|General notes||Most suitable for applications used exclusively by Harvard users.||We strongly recommend not using PIN2 in new applications. CAS offers a simpler alternative, since it does not involve cryptography operations. If it is truly necessary for you to use PIN2, please contact firstname.lastname@example.org.||Provides a good fit for internal user applications if the app is from an SaaS vendor or is an out-of-the-box product/tool/framework that supports SAML.|
|Federation support||No.||No.||Supports InCommon identity federation. If a future need for external users may arise, use this protocol.|
|Support for all HarvardKey login types||All.||All.||All except XID.|
|Authentication response to application||Username, login type, and attributes.||PIN2 token containing username and login type.||eduPersonPrincipalName (or uid in some cases) and attributes of the authenticated user. (Note that these are attributes/opaque identifiers specifically associated with the SAML protocol.)|
|Environment and tools support||A large number of open-source libraries available for almost all commonly used environments and languages.||IAM provides libraries and sample configuration for most common environments used at Harvard.||Usually installed as web server module and a daemon process independent of application.|
|Configuration||Very simple. No cryptography work involved.||Cryptography work involved. Application must validate the signed token.||SAML Service Provider (SP) configuration is more involved.|
|Supported Version||CAS 1.0 and 2.0.||PIN token version 1 and 2.||SAML 2.0.|
|Authorization||None.||Coarse-grained centralized authorization service is available.||None.|
|Attribute Release||Releases attributes to facilitate authorization in application.||Releases attributes to facilitate authorization in application.||Releases attributes to facilitate authorization in application.|
After you've reviewed this information, you may find that both CAS and SAML are suitable for your application. If that's 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 — for example, 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. On the other hand, 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.Need more information to help you make a decision? Click below for additional details on how each protocol works.