Skip to content
Proof of concept for lua-resty-openidc as a Traefik forward auth server
Lua Dockerfile Shell HTML
Branch: master
Clone or download
Latest commit c02a0ff Dec 18, 2018
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
nginx-root
openresty-docker
.gitignore
.gitmodules
LICENSE
README.md
docker-compose.minimal.yml
docker-compose.nested.yml
docker-compose.yml
secrets.env

README.md

traefik-idc-demo

BackgroundDemo

NOTE: This repository contains a submodule pointing to my fork of lua-resty-openidc. Please run git submodule update --init --recursive after cloning the repository OR use the --recurse-submodules flag when cloning.

In its current state, the provided compose files are for reference only, taking into account a more complicated setup specific to my server that is also hosting the demo, and therefore will not work anywhere else without modification.

The auth.lua script was written to slightly modularise the added authentication bypass functionality (WIP; disabled with examples) where the forward auth server can skip the OIDC authentication based on the client IP and requested domain. Alternatively, the configuration can be inserted directly into default.conf as per the official instructions, with careful adaptation of the HTTP status codes handling required for forward auth servers.

Compose files

docker-compose.yml [Tested] [Active]

  • Expects an external Traefik container that is watching Docker changes; needs network access to OpenResty.
  • Includes its own OpenResty instance as the forward auth server; needs internet access to the identity provider.

docker-compose.nested.yml [Tested]

  • Includes an internal Traefik container that is currently set up to run behind another external Traefik container, where the latter provides ACME/TLS termination. The command gives an idea of the minimal configuration required for Traefik.

docker-compose.minimal.yml

  • In production, both Traefik and the OpenResty auth server would likely be external. This provides an example of solely the configuration required for a protected service and is closest to what I have experimentally deployed.

Live demo

Visit the protected endpoint and login with test:test.

You can’t perform that action at this time.