Online Advising system

Support for Byron Becker's development project.

Planning Document

Rationale for separate container

We want authentication to be handled by Apache, which we know how to configure and which provides the authentication information (i.e., logged in userid) to CGIs via the REMOTE_USER variable. In particular, this makes setting up CAS trivial.

If there was a CAS module for the current version of Play, it might make more sense to configure Play that way, even though it's not really appropriate for individual applications to handle their own authentication. But apparently there isn't.

The Play framework which Byron is planning to use for this application runs as an HTTP(S) server. In order to ensure that requests passed to Play by Apache are actually from Apache, it either needs to check client certificates (as is done by services108.cs to ensure that only the new web server can send it requests), or network configuration has to be such that only Apache can send it requests.

Byron can't seem to find a way of configuring Play to require and check client certificates.

The tightest possible network configuration is to allow connections only from localhost (i.e., listen on 127.0.0.1 only). This would still allow anybody logged into the machine on which it is running to send it requests, including specifying any REMOTE_USER they want. So the idea is to have a container that only application administrators can log into.

This also fits well with the suggestion from the Security group that this application should run on its own web server.

Sysadmin Documentation

The ASIS / OAT advising system ( advising.uwaterloo.ca CNAME oat-102.cs.uwaterloo.ca ) is run on an LXC container currently hosted on m3-3101-2.cloud.uwaterloo.ca, an ubuntu1010 container host.

Access is via root from cscf. The application runs as java processes running as user oat-demo. For questions, speak to ijmorlan or bwbecker. Byron has some server details recorded in PlayWebServer