IdP: add safeguard --idp-h-key and also require --xff-src

This commit is contained in:
ed
2024-03-12 22:57:47 +00:00
parent e8b7f65f82
commit d71f844b43
7 changed files with 55 additions and 7 deletions

View File

@@ -21,8 +21,11 @@
ansi # enable colors in log messages
#q # disable logging for more performance
# since copyparty is only accessible through traefik, disable safetycheck on x-forwarded-for
xff-src: any
# if we are confident that we got the docker-network config correct
# (meaning copyparty is only accessible through traefik, and
# traefik makes sure that all requests go through authelia),
# then disable the reverse-proxy source-ip safety check like this:
#xff-src: any
# enable IdP support by expecting username/groupname in
# http-headers provided by the reverse-proxy; header "X-IdP-User"

7
docs/idp.md Normal file
View File

@@ -0,0 +1,7 @@
there is a [docker-compose example](./examples/docker/idp-authelia-traefik) which is hopefully a good starting point (meaning you can skip the steps below) -- but if you want to set this up from scratch yourself (or learn about how it works), keep reading:
to configure IdP from scratch, you must place copyparty behind a reverse-proxy which sends all requests through a middleware (the IdP / identity-provider service) which will inject a set of headers into the requests, telling copyparty who the user is
in the copyparty `[global]` config, specify which headers to read client info from; username is required (`idp-h-usr: X-Authooley-User`), group(s) are optional (`idp-h-grp: X-Authooley-Groups`)
* it is also required to specify the subnet that legit requests will be coming from, for example `--xff-src=10.88.` to allow 10.88.x.x, and it is recommended to configure the reverseproxy to include a secret header as proof that the other headers are also legit (and not smuggled in by a malicious client), telling copyparty the headername to expect with `idp-h-key: X-Totes-Legit`