idp: docs

README.md

@@ -1264,7 +1264,9 @@ replace 404 and 403 errors with something completely different (that's it for no
 
 replace copyparty passwords with oauth and such
 
-work is [ongoing](https://github.com/9001/copyparty/issues/62) to support authenticating / authorizing users based on a separate authentication proxy, which makes it possible to support oauth, single-sign-on, etc.
+you can disable the built-in password-based login sysem, and instead replace it with a separate piece of software (an identity provider) which will then handle authenticating / authorizing of users; this makes it possible to support oauth, single-sign-on, etc.
+
+a popular choice is [Authelia](https://www.authelia.com/) (config-file based), another one is [authentik](https://goauthentik.io/) (GUI-based, more complex)
 
 there is a [docker-compose example](./docs/examples/docker/idp-authelia-traefik) which is hopefully a good starting point (alternatively see [./docs/idp.md](./docs/idp.md) if you're the DIY type)
 

docs/examples/docker/idp-authelia-traefik/cpp/copyparty.conf

@@ -25,7 +25,7 @@
   # (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
+  xff-src: any
 
   # enable IdP support by expecting username/groupname in
   # http-headers provided by the reverse-proxy; header "X-IdP-User"

docs/examples/docker/idp/copyparty.conf

@@ -26,6 +26,21 @@
   idp-h-usr: x-idp-user
   idp-h-grp: x-idp-group
 
+  # but copyparty will refuse to accept those headers unless you
+  # tell it the LAN IP of the reverse-proxy to expect them from,
+  # preventing malicious users from pretending to be the proxy;
+  # pay attention to the warning message in the logs and then
+  # adjust the following config option accordingly:
+  xff-src: 192.168.
+
+  # an additional, optional security measure is to expect a
+  # secret header name from the reverse-proxy; you can enable
+  # this feature by setting the header-name to expect here:
+  #idp-h-key: shangala-bangala
+
+  # convenient debug option:
+  # log all incoming request headers from the proxy
+  #ihead: *
 
 [/]      # create a volume at "/" (the webroot), which will
   /w     # share /w (the docker data volume)

docs/idp.md

@@ -4,4 +4,4 @@ to configure IdP from scratch, you must place copyparty behind a reverse-proxy w
 
 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`
+* 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: shangala-bangala`