How the Rutgers CAS Logs in Users

[Voxelghiest]

The Rutgers Central Authentication System (CAS) centralizes logins across Rutgers-affiliated services (dashboard, Canvas, etc.), which allows users to use the same login info each time. This ticket aims to provide a more detailed documentation of how that process works.

[Voxelghiest]

It took some digging, but I found a section of the Rutgers OIT website that documents how the Rutgers CAS works. There's also a series of articles that go into more detail on other aspects of the CAS. These articles are mostly from 2015, which means they are somewhat out-of-date, but I couldn't find anything more recent.

The Rutgers CAS is built off of a CAS service provided by Apereo. In short, it works by redirecting user logins from various services to a central server that performs the authentication process and then returns that information to the client application. Each application is responsible for handling that process and utilizing the authorization information as needed.

On their website, Apereo states that there are officially supported CAS client libraries for .NET, Java, PHP, and Apache. Unfortunately, I could not find any official documentation for a JavaScript or Elixir library, which are the two languages that the Hubs ecosystem uses. I will investigate if an unofficial library exists, because the prospect of writing a library ourselves seems daunting.

[Voxelghiest]

There are a few JavaScript libraries that claim to provide CAS integration (e.g. koa-cas, cas-authentication, cas-validate). However, they all require the use of Express, which is a JavaScript framework that I'm unfamiliar with, and furthermore, all of the libraries I could find were years old and rarely updated, which is a definite concern when dealing with security and authentication.

[Voxelghiest]

So apparently Express is a separate framework that can be used for server deployment or as middleware for other frameworks to perform useful tasks. According to my discussion with @yuriaru, if we were to use Express, it would be as a separate server process that facilitates the authentication process between Hubs Client and the Rutgers CAS.

A second thing I've found relates back to Reticulum. Ueberauth is an Elixir library for authentication, and a community-written supplementary module of Ueberauth (called a "strategy" by the Ueberauth documentation) exists for CAS. We could integrate this module into the Reticulum server and use that as the middleware for authentication routing, which in my opinion would be a better option for Hubs specifically.

One of the other things I like about Ueberauth compared to the various JavaScript libraries I've been researching is that Ueberauth is very active, having been updated as recently as a month and a half ago. It seems more professional, and it has more accessible and concise documentation. Those are admittedly subjective qualities, but they will make the authentication pipeline not only easier to set up, but also easier to update, modify, and maintain in the future.

[Voxelghiest]

I'm pausing further work on this ticket in favor of #58 for the time being.