OIDC

OpenID Connect at CSAIL

Most web applications at CSAIL are authenticated by a mechanism called OpenID Connect (OIDC). This involves a central CSAIL OIDC authentication service that our various web apps can use to authenticate and authorize CSAIL members. (It uses the same protocol as MIT’s Touchstone but is a separate implementation using CSAIL’s account system.)

What is OpenID Connect?

There’s a technical description of OIDC you can read at http://openid.net/connect/ if you want to know all the details, but in short, OIDC is a service that we run at CSAIL on our own servers that allows you to authenticate to services like WebDNS, DHREG, the CSAIL website, and many more, by using your CSAIL Kerberos account.

Using OpenID Connect

Most of the time, OIDC is relatively transparent to you. You will use OIDC when you need to authenticate to a secure CSAIL website. When you first visit a secure CSAIL website, you are temporarily redirected to the OIDC server (you’ll see the URL in the address bar change to something starting https://oidc.csail.mit.edu/...). There you will simply enter your CSAIL username and password and click “Login”. You are then returned and logged into the secured website.

Note

Your first time authenticating to a website, you will first will need to authorize it. This is the process of telling our OpenID Connect cluster that you do want it to tell the web app whether you’re authorized to use that application or not. You will only need to do this once per website. For example, after authorizing https://groups.csail.mit.edu/tig/oidc/ the first time, any website on groups.csail.mit.edu will not require re-authorization.

If you’re on a system where you regularly get CSAIL Kerberos tickets already – like a CSAIL Ubuntu workstation – then you may find it convenient to use your existing Kerberos tickets to log in to OIDC. See Configuring Browsers below.

OIDC for developers and website administrators

If you are the administrator of a CSAIL website that should be restricted to current CSAIL members, or some subset thereof, see Restricting your website with OIDC and .htaccess

Configuring browsers to use existing Kerberos tickets

Advanced / Optional

If you’re on a system where you regularly get CSAIL Kerberos tickets already – like a CSAIL Ubuntu workstation – then you may find it convenient to use your existing tickets to authenticate.

Unfortunately, Ubuntu is recently shipping web browsers as isolated “Snap” containers, which do not necessarily have access to the full filesystem or to your Kerberos tickets from the operating system. Therefore, depending on your web browser, for Kerberos authentication to work, you might need to replace the Ubuntu-provided web browser with one built for the operating system as a normal .deb package.

Firefox

For Ubuntu users: Firefox as provided by some versions of Ubuntu doesn’t have access to your Kerberos tickets. To make Kerberos authentication work in those versions of Ubuntu, you may need to replace the Ubuntu-provided Firefox snap package with a .deb package; details are beyond the scope of this page but you can find information about how at omgubuntu.co.uk or by searching for something like “replace Firefox snap with deb Ubuntu”.

Once you’ve done that (or if you’re on a Mac), Firefox supports Kerberos authentication, but it requires a bit of extra configuration. You’ll need to go to about:config (if you haven’t done this before, Firefox will ask you if you really want to) and set the preference network.negotiate-auth.trusted-uris to .csail.mit.edu

If your system is particularly weird, you might also have to set network.negotiate-auth.using-native-gsslib and/or network.negotiate-auth.gsslib – ask TIG to help you with these settings if just setting trusted-uris doesn’t work.

We haven’t found a way to make Firefox use Kerberos on Windows reliably. The procedure described above works for Firefox on other operating systems with official Firefox binary packages.

Safari

Whether Safari supports Kerberos authentication depends on the version of macOS and Safari you have. Kerberos login to OIDC has been confirmed to work automatically in Safari 10.1 on Yosemite and newer macOS releases, with no special configuration.

Chromium/Google Chrome

As with Firefox, Chrome requires that domains be explicitly permitted to use Kerberos authentication. Furthermore, on Windows, Chrome uses the system SSPI libraries and not the MIT Kerberos for Windows or AuriStor Heimdal libraries which you may already have installed. How to configure Chrome policies unfortunately also varies across the three platforms.

Integrating OIDC Authentication Into Your Apps

If you are writing a custom web application, and would like to allow users with CSAIL accounts to log in, you can register a client with the CSAIL OIDC Service. To do so, you must have a current CSAIL account. Get started by visiting the self-service client registration URL at: https://oidc.csail.mit.edu/manage/dev/dynreg.

OIDC authentication modules are available for all major web frameworks.

History

Prior to adopting OIDC, CSAIL used web client certificates for similar purposes. This involved a web form people could use to download an SSL client certificate that they could install in their browser. For various reasons, including the fact that web browsers’s stopped supporting some of the standards involved in generating and issuing such certificates, CSAIL stopped issuing web certificates and switched to OIDC.

IS&T still supports web client certificates for Athena accounts in a few obscure places, but for the most part they’ve also replaced client certificates with their own OIDC implementation, as part of MIT Touchstone (FAQ).

CSAIL websites and web pages that do NOT use OpenID Connect

As far as TIG-managed and TIG-maintained web applications intended for general use, there are two that don’t use OpenID Connect. Both of these are email-related, and both can’t use OpenID Connect because not all of the people who need to authenticate to them are current CSAIL members.

In addition to those two web applications managed by TIG, some individual web pages or research web applications deployed by CSAIL members may have their own ad-hoc passwords. For instance, a research group might make a dataset available, but require registration before downloading it, so they might password-protect the dataset download page with passwords they set up. Or a research project might have a wiki that a handful of CSAIL members plus a handful of outside collaborators need access to, and might implement a set of usernames and passwords specific to that wiki.

(For webpages or web applications that should only be accessed by current CSAIL members, or by a certain identifiable subset of CSAIL members, using OIDC to control access is often the best choice, even for research-group maintained websites. If you have an access-control need for your website and you’re not sure whether TIG’s OIDC infrastructure is a good way to address it, feel free to send mail to help@csail.mit.edu.)