Single Sign-On


Without single sign-on (SSO), users have to enter their ID and password each time they wish to access a HarvardKey-protected website or application. SSO is intended to improve the convenience of the system for the end user and to create a more integrated feel within the Harvard online environment.

When a user is successfully authenticated to HarvardKey, the system records the "login event." Users with a valid login event record are considered to be logged in to the entire system and, unless the application registers a timeout period to override this behavior, a user can access any other protected website within the current browser session without having to manually re-enter login credentials.

Each time the user tries to access a different protected resource, HarvardKey analyzes the login event record, the application's registered timeout values, the login type used when the user manually authenticated, and the application's registered login types. If the system determines that the user is eligible for single sign-on, it passes the user through to the site. If not, the user is prompted for manual re-entry of credentials. Accessing an application within a different browser session or with different browser software also results in being prompted for credentials.

Although a particular application may require users to re-enter credentials after a certain period of time, as far as HarvardKey is concerned, a user is authenticated until their browser session ends or the user visits the logout page. For this reason, it is strongly recommended that applications implement a logout link or button that, apart from invalidating the local login state, also invokes the link to the HarvardKey logout page, resulting in that user being completely logged out of HarvardKey-protected resources.

Please note that SSO does not affect the local login state of a Harvard-protected application, nor does it affect the communication between HarvardKey and protected applications.

Security Considerations

If not used properly, SSO carries a risk of reduced security. IAM has placed warnings of potential security issues throughout HarvardKey, but we have no way of forcing users to adhere to good security practices. Therefore, we allow applications to limit the amount of time they will accept since a user's last manual authentication, force re-authentication after a period of idle time, or even refuse to accept SSO assertions entirely. When implementing SSO, application owners should weigh the security issues and decide on the policy that is most appropriate. Primary considerations are:

  • Leaving a computer unattended while logged in to HarvardKey
  • Forgetting to log out of the system when finished using Harvard-protected applications

In a worst-case scenario, a user logs in from a publicly accessible Internet kiosk, then walks away without logging out or closing the browser. Subsequent users are then able to impersonate the first user and use HarvardKey-protected applications using the first user's access rights. Similar risks arise from students who share their dorm room computers with roommates, employees who walk away from their desks during lunch, etc.

Setting an idle session timeout can obviously, reduce this risk. However, this should also be weighed against usability. To address this, when application owners register their applications, they may specify a timeout value in minutes since the last manual authentication. If an application specifies a timeout of, for example, 20 minutes, and the record of the user's last login event is older than that limit, the user will be prompted for credentials again. Applications that refuse to accept SSO completely may specify a timeout of 0.


We recommend that application owners do the following:

  • Choose an appropriate single sign-on duration (browser session length, absolute duration, none) to indicate how often a user must manually enter credentials to gain access to your website. This will vary widely depending on the nature of the application; for example, a portal that provides personalized information but not access to secure data may choose a value on the order of days, weeks, or months, while an HR application may choose to exclude SSO entirely. (Note that the login page protection model is the only option for applications opting out of single sign-on.)

    The value you choose should depend on the most restrictive needs of the application. For example, if you have both regular and superuser functions — in which superuser access needs to be locked down tightly, but regular access does not — you have two options:
    • Choose an SSO duration for both functions based on the need for superuser security. 
    • Register each function as a separate application with HarvardKey, each with its own SSO duration. Keep in mind that the SSO option is maintained in the AccessGate configuration, and this option would require two AccessGate installations.
  • Provide a HarvardKey logout page link or button in a prominent location in your application (or incorporate a callback to the HarvardKey logout page when implementing a link to your own local logout function) to remind users of the need to log out when finished.