Mocking CAS Users in Local Development

At the 2021 IT Symposium, Michael Irwin spoke about the benefits of “persona-driven development”, or the idea of developing personas representing real users for local development and testing (slides are available here). The main benefits are:

Everyone on the team has the same mental model of users/roles - when many of our real users wear different hats for the many roles they carry, it’s easy to get different mental models of what each user should be able to do within our applications. By having a consistent set of personas shared by the entire team, we can more easily be on the same page.
No longer tied to real auth - if these personas are used in development and testing, we no longer are tied to the lifecycle of real users who change teams, change roles, or change jobs.
Supports automated testing - if we can mock users, we can safely include the credentials in our codebase for automated testing

A quick warning

When NOT to mock users

You MUST NOT mock users in development or testing environments if you cannot mock the data in its entirety. If you are still connecting to real data (even old snapshots), you open the possibility of privilege escalation and the leakage of data.

Running a Mock CAS

Recognizing that CAS is merely a protocol, we can swap out the implementation in local dev from using the main VT Login to a local CAS server. One that has been commonly used is conveniently packaged as a container image, allowing us to easily spin it up.

The config file

In order to specify people and their attributes, we need to create a JSON-based config file that specifies the users and their attributes. The config file structure is as follows:

{
  "<username>": {
    "attributes": {
      "<attribute1>": "<attribute1-value>",
      "<attribute2>": [
        "<attribute2-value-a>",
        "<attribute2-value-b>"
      ]
    }
  }
}

Each user can also “inherit” another user, letting you build out a set of default attributes that are shared by all. An example config file is below:

{
  "DEFAULT": {
    "attributes": {
      "affiliation": "EMPLOYEE",
      "groupMembership": "valid-user"
    }
  },
  "fletcher": {
    "inherit": "DEFAULT",
    "attributes": {
      "uid": 1,
      "displayName": "Jordan Fletcher",
      "groupMembership": [
          "admin",
          "power-user"
      ]
    }
  }
}

Sample Compose File

The following Compose file will start up our Mock CAS server, mounting the config file into the container (named cas-attributes.json), and then specifying its location using the ATTRIBUTES_JSON_URL environment variable. It’ll be made available through the Localhost Proxy, giving us a signed/trusted cert for local development.

Important note: the ability to use a local mock CAS can be used even if the app under development is not containerized. But, depending on ports your app is using, you may need to adjust the ports the proxy is using.

services:
  proxy:
    image: dtr.it.vt.edu/devcom/devcom-localhost-proxy:traefik-2.3
    ports:
      - 80:80
      - 443:443
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      default:
        aliases:
          - cas.localhost.devcom.vt.edu

  cas:
    image: soulwing/cas-mock-server
    volumes:
      - ./cas-attributes.json:/cas-attributes.json
    environment:
      ATTRIBUTES_JSON_URL: file:///cas-attributes.json
    labels:
      traefik.http.routers.cas.rule: Host(`cas.localhost.devcom.vt.edu`)
      traefik.http.services.cas.loadbalancer.server.port: 8080

Full Example

For a full demo, you can checkout the repo for the sample app Michael used for his Symposium talk. While it’s PHP (making it hopefully easier to follow along), it demonstrates the ability to run an app in local development with the mock CAS.