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.
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.
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.
- Our webmail server instead uses CSAIL IMAP (email) passwords, which are distinct from CSAIL Kerberos passwords for security reasons. (Some alumni still use their CSAIL email accounts and may need access to our webmail server. On the other hand, plenty of current CSAIL members forward their mail elsewhere and do not use our IMAP server or our webmail interface to it.)
- While our mailing-list server does use OIDC to authenticate the form that lets you create a new mailing list (which means you have to be a current CSAIL member to create a new mailing list), the individual mailing lists it hosts each have their own sets of passwords, including administrative passwords so the list owners and moderators can manage the list and member passwords so list subscribers can adjust their subscription options.
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.)