Queue

A queueing system to be used at labs at EWI (tudelft.nl).

Requirements

• Java 8

Usage

Run website from IDE

1. Install IntelliJ IDEA Professional (free for students)
2. Import project from Gradle model
3. Start the project by right-clicking QueueApplication and clicking 'Run'

Run website from CLI

1. gradle build
2. sudo java -jar build/libs/queue-0.0.1-SNAPSHOT.jar
3. Visit http://localhost:8080/

Deployment

The deploy/ directory contains an Ansible playbook that can be used to provision the machine. Specifically, it contains:

• an nginx site config (default) with an upstream for tomcat on port 8080 together with config for a letsencrypt generated SSL certificate.
• a SystemD configuration (queue.service) that runs the jar at /var/www/queue/queue-0.0.1-SNAPSHOT.jar as root on startup and logs to /var/log/queue.log.
• an ansible config that installs Oracle java 8, nginx, postgres, haveged, the SystemD job, the jar, and starts the services.
• an application.properties file with application-specific configuration, such as the database settings.

To run the playbook, first replace the hostname and your SSH key in deploy/hosts, then run ./deploy/run.sh.

Note that the current application.properties contains spring.jpa.hibernate.ddl-auto=create which will drop and create the database upon reboot!

Configuration

See application.properties. Chrome does not yet fully support the Web Push API and uses GCM to handle sending and delivery of push messages. To use the GCM API you need a GCM API key. This page explains how to obtain one.

You can place an application.properties on the classpath which overrides the application.properties in the jar itself.

Nowadays, Chrome supports VAPID (Voluntary Application Identification) for Web Push API and it is no longer necessary to obtain an API key. The Web Push library should be updated to the latest version that I'm maintaining at https://github.com/MartijnDwars/web-push. For VAPID, we need to generate yet another keypair..

Environments

The system distinguishes two profiles: development and production. Use the application.properties file to set the active profile. The active profile has the following impact:

• The DatabaseLoader, which loads the database with dummy data, is only run if the development profile is active.
• The error.html page only shows stack traces if the development profile is active.

Domain

• A Request is always initiated by a student. At some point, it will be handled by an assistant.

Roles

A user has a single default role and a single contextual role for every course that he participates in. This distinction is necessary because, for example, a teacher may not be a teacher in every course. The default roles are STUDENT, TEACHER, and ADMIN. The contextual roles are STUDENT, ASSISTANT, MANAGER and TEACHER.

A user can have at most one contextual role within a course. An ASSISTANT is able to handle requests. A MANAGER can do everything an ASSISTANT can, but may also manage assignments and labs. A TEACHER can do everything an ASSISTANT can, but can also remove the course and change the course's name.

The default roles form a hierarchy. That is, an ADMIN can do everything a TEACHER can, and a TEACHER can do everything a STUDENT can. A user with default role STUDENT has no special permissions. A user with default role TEACHER is allowed to create courses. A user with default role ADMIN is allowed to change a user's default role.

When an ADMIN operates within a course, he acts as a TEACHER. It is adviced to use the admin account solely for administrative usages (such as setting up a course).

Security

• Passwords are encrypted with bcrypt, which protects against rainbow table attacks and remains resistant to brute-force attacks when computing power increases.
• All forms are accomodated with an _csrf field to protect against CSRF attacks.
• We only support HTTPS connections, because supporting both HTTP and HTTPS is too much of an effort (and there is little to no reason to support HTTP). Spring Security will make sure the HTTP Strict Transport Security (HSTS) headers are set. In development mode, make sure you accept the certificate. On OS X, adding keystore.p12 to Keychain will get you a green padlock in Chrome. This is required for push notifications, among others.
• All Users have a Role, which is one of: STUDENT, ASSISTANT, TEACHER, ADMIN.

SSO

SAML provides Single Sign On (SSO). The Queue system acts as a Service Provider (SP). It requests and obtains an identity assertion from the identity provider (TUDelft gatekeeper). By default, only identity assertions with a max age of 7200 seconds are trusted. This can be changed by updating maxAuthenticationAge on the WebSSOProfileImpl object. Alternatively, you can force the IDP to re-authenticate the user by setting forceAuthN to true on the WebSSOProfileOptions object.

In development you may not want to go through the SAML process. The traditional login page is still available at /login. This requires that a User with a username and password exists.

Crypto

The SAML messages are cryptographically signed. The file security/samlKeystore.jks is a Java keystore. It has no password (when prompted for a password, enter the empty string). The development keystore contains a key with alias apollo and password nalle123. For production, you'll want to:

1. Create a PKCS12 file using your private key and a CA signed certificate of it. You can use openssl command for this: openssl pkcs12 -export -in /etc/ssl/certs/queue_ewi_tudelft_nl.crt -inkey /etc/ssl/private/queue.ewi.tudelft.nl.key -certfile /etc/ssl/certs/queue_ewi_tudelft_nl.crt -out testkeystore.p12
2. Create a Java keystore (.jks file) using the keytool: keytool -importkeystore -srckeystore testkeystore.p12 -srcstoretype pkcs12 -destkeystore keystore.jks -deststoretype JKS
3. To list the keys in the Java keystore: keytool -list -v -keystore keystore.jks

(source)

Metadata

The SP metadata can be generated automatically. To do so, visit /saml/metadata. The browser will provide a file spring_saml_metadata.xml. You need to deliver this file to the TU Delft.

Push

Notifications are sent using the Push API. The Push API is experimental and we expect things to break. Note that the Push API requires HTTPS.

Apache2 config

With regards to deployment and the high number of students, ensure that the value for MaxRequestWorkers in Apache2 is high enough. For example, for about 450 first year students, the number 250 was found to be suitable. The file to edit for this is mpm_prefork.conf and the directive is MaxRequestWorkers.