Pihole’s authentication is based on a single password that is used for logging in into the FTL webserver and used for authentication in API requests.
There is no option to enable basic auth, which would allow the reverse proxy to add the Authorization header in the requests routed to pihole
There is no support for Remote-User to forward an externally authenticated user ID
Disabling the password by setting FTLCONF_webserver_api_password=’’ allows authentication to be handled externally and not be faced with the Pi-hole login screen, but it also exposes the API within the network as it can now be reached with password ` `.
Request:
Option A (better, allows logging by name): Provide option to configure a request header (e.g. ‘Remote-User’) and its value(s) which allows the admin to setup one or more user ID’s that need to be considered authenticated when the header and known value is present in a request to the webserver.
Option B: introduce config FTLCONF_webserver_external_login, defaulted false, when true any request to /admin is considered authenticated.
Option C: define a specific header (e.g. X-FTL-Password) and implement a mechanism to use this forwarded and authenticate the session automatically. (This is only sent from the reverse proxy server to the application, not exposed externally.)
I want to support the problem statement. I would like to replace the single user/single password with OIDC. I don´t really care, whether pi-hole validates tokens itself or whether I use nginx to validate and enforce authentication.
I am also using nebula-sync to replicate configuration between multiple pi-holes, just disabling authentication in pi-hole and just using the nginx doesn´t work for me.
I definitely would prefer a solution that allows to log user names (and allowing me to use "nebula" or the like for replication).
Even something as simple as just separating the dashboard password from the API tokens would be sufficient.
I access my dashboard via an external reverse proxy. Would prefer to have the dashboard accessed via my SSO solution while having the API access secured by the standard tokens all plugins expect.
