Overview of Authentication with HarvardKey
Authentication is the primary service offered by HarvardKey Identity Provider (IdP) and the first step enabling Harvard users to access web applications. Authentication determines whether a user is the entity they claim to be when they attempt to log into an application integrated with HarvardKey. To perform authentication, HarvardKey IdP and the software component managing the application transfer data through well-defined sets of steps and data formats collectively known as an authentication protocol. When a user logs onto an application, the IdP requires unique credentials in the form of a username and password to validate the user’s claim. It then verifies the correctness of the credential against those that exist in the IAM user directory. For Harvard-affiliated users, the process includes a second-step verification method using the DUO service. Once the user is authenticated, IdP returns an authentication response (or assertion) back to the application.
The response is a promise to the application that HarvardKey knows who the user is.
HarvardKey supports three authentication protocols: CAS, SAML, and OIDC. While each protocol will function with the Harvard IdP, an application may be more or less suitable with a protocol based on their characteristics. A description of each protocol and recommendations for your application are found below.
Understand your Options for Authentication Protocols
CAS
The CAS authentication flow involves communication between two components:
- CAS Server: System entity implementing multiple protocols including CAS protocol for authenticating users and granting access to applications that utilize CAS protocol for authentication.
- CAS Clients: The software component that protects the CAS protocol using applications and retrieves the identity of the granted users from the CAS server. The list of open source CAS Clients are available here: https://apereo.github.io/cas/6.6.x/integration/CAS-Clients.html.
Features
- Widely used in academic institutions
- Primary implementation of the protocol is an open source multi-protocol IdP (https://apereo.github.io/cas/index.html)
- Trust between CAS client and CAS server relies on client registration and CAS server certificate validation
Is CAS right for you?
If you have a traditional web application (an application that reloads the full page when users navigate using links) deployed in the Harvard local network, then CAS may be a strong option to consider. The application receives user identity information securely without having to perform any cryptographic operations, keeping implementation lean and simple.
SAML2
The SAML authentication flow involves communication between two components:
- SAML Identity Provider (IdP): System entity implementing SAML protocol that issues authentication assertions– messages sent to the Service Provider (SP) validating their authentication of the user. HarvardKey uses Shibboleth IdP.
- SAML Service Provider (SP): System entity that protects the application that a user is trying to access. SPs receive the authentication assertion from the IdP to allow the user to access the application.
Features
- Widely used by SaaS vendors
- Suitable for traditional web applications
- Works with InCommon Federation
Is SAML right for you?
If you are interested in accepting users from outside Harvard, SAML may be the best choice. SAML provides the specifications to build cross-institution or cross-domain authentication through access control infrastructures known as "identity federations." Applications can join an identity federation such as InCommon using the SAML protocol, making it easier to allow access to users from other institutions that are also part of InCommon.
SAML may also be a good choice if you're using a Software as a Service (SaaS) solution from an outside vendor, since many of these — as well as many other out-of-the-box frameworks and products — support SAML for authentication.
OIDC
OIDC authentication flow involves communication between two components:
- OpenID Connect Provider (OP): System entity implementing OIDC protocol for authenticating end users and providing authentication response (or OIDC claims) to applications (known as Relying Party or RP).
- Relying Parties (RP): Software component that protects the OIDC protocol using applications and retrieves the identity of the granted users from the OIDC OP.
Features
- Based on OAuth 2.0 Protocol
- Modern protocol suitable for single page applications (SPA) and mobile applications
- Registration between RP and OP is required
Is OIDC right for you?
OIDC is appropriate if you are registering an application with any of the following components:
- Single Page Application (SPA)
- Mobile application
- Traditional web application
PIN
PIN is Harvard’s home grown authentication protocol that predates the availability of standard protocols. It is still used by a number of internal applications; however, no new applications may be integrated with HarvardKey using the PIN protocol. This protocol will be removed from HarvardKey Authentication Service after migrating all PIN applications to a suitable alternative protocol.