There are circumstances when having a built-in authentication scheme is not practical. For these we should enable a wiki site to be wrapped in a layer that protects the site.
We acknowledge that we will never be able to provide support for every possible authentication scheme, or integration with corporate security solutions. So, we foresee that it will be necessary to accept the user's identity from an outer security layer.
This layered approach will be provided by the use of a proxy, that handles all wiki requests ensuring that only authorized requests reach the wiki server.
While how to deploy this outer layer is outside our scope. But, a modular authentication plugin should be provided to demonstrate picking up the user's identity from this outer layer.
.
As a proof of concept, we experimented with this Caddyfile to test authentication in a local reverse proxy.
:80, :443 gzip tls self_signed basicauth / {$ACCOUNT} {$PASSWORD} proxy / {$ORIGIN} { transparent }
Here follows a docker composition which puts the Caddyfile above as a reverse proxy in one container in front of a separate container (also with caddy) acting as the protected origin server:
version: "2.2" services: proxy: image: dobbs/proxy:latest init: true ports: - "2015:80" - "2016:443" volumes: - "./Caddyfile:/etc/proxy/Caddyfile" environment: ORIGIN: "origin:2015" origin: image: abiosoft/caddy:latest
An experiment left as an exercise for the reader would put wiki in place of the `origin` in this composition. In this case readers and authors would have to authenticate with the shared `$ACCOUNT` and `$PASSWORD`. And the author would have to further authenticate with wiki by providing the friends secret, for example. Not sure if the basicauth would prevent using other OAuth providers like Github or Twitter or Google.