Support for trusted header / forward auth

[TilBlechschmidt]

trafficstars

Is your feature request related to a problem? Please describe. I have existing SSO infrastructure using Authelia backed by an LDAP server and am running Part-DB in Docker behind a reverse proxy. Though the specifics don't really matter.

Looking into the available authentication methods, I noticed that only SAML is supported which Authelia does not natively support. Hence I am not able to use SSO without additional software in between (namely Keycloak as mentioned in the docs) or switching to a different IDP.

---

Describe the solution you'd like Trusted header / forward auth is an authentication scheme where a reverse proxy handles the authentication logic including any interaction with the ID provider. It allows access to the application once the user has been successfully authenticated.

A set of headers is appended to the original request which contain details about the logged-in user like the username, groups, and other details (similar to SAML). This is then forwarded to the application.

While it is possible to use forward auth today to at least protect Part-DB by an SSO barrier, it requires giving the anonymous user full permissions as it is not possible to discern users without falling back to the built-in auth.

My suggestion would be to add a configuration flag which disables the built-in login system and instead takes the logged in username from a configurable request header.

---

Describe alternatives you've considered

• Keycloak indirection
  • Setting up and maintaining Keycloak is rather complicated compared with forward auth
  • Trusted header auth is conceptually very simple and supported by many popular ID providers like Authelia and Authentik hence I would see it as a beneficial feature for Part-DB to support natively given the likely very minimal code changes required

---

Additional context I am unfortunately not fluent enough in PHP to directly/confidently make the required changes. However, I'd be happy to provide answers to any questions, setup a reverse proxy for testing, and write some user documentation / submit a PR to Authelia to include Part-DB in their integration docs (if desired).

Notable disadvantages of forward auth:

• Strict firewall rules or correctly configured TRUSTED_PROXIES mandatory
• Anonymous access is hard to do
• Static assets are not reachable without logging in
  • Whitelists can usually be configured
• Not (really) usable for API auth
  • Commonly the API paths are whitelisted and API usage authenticated separately via e.g. tokens

[jbtronics]

In principle, this should be possible to implement. However it seems that nobody has ever done something like this with Symfony before and there is no finished implementation of it.

So one would need to write a custom authentication for it.

[mindsolve]

I'm sorry if I am missing something here, but to me it looks like Symfony Security supports this out of the box: https://symfony.com/doc/current/security.html#remote-users. The basic functionality (i.e. already registered user) works with the following change to the config/packages/security.yaml:

diff --git a/config/packages/security.yaml b/config/packages/security.yaml
index 95f5c6b1..5f3e22f9 100644
--- a/config/packages/security.yaml
+++ b/config/packages/security.yaml
@@ -51,6 +51,10 @@ security:
                 use_referer: true
                 default_target_path: '/'

+            remote_user:
+                provider: app_user_provider
+                user: HTTP_REMOTE_USER
+
             logout:
                 path: logout
                 target: homepage

Setting the Remote-User-Header to the username of an existing user automatically logs them in.

I see the following problems/points to improve/check:

• Users with the flag "password change required" are basically locked out (no actions possible other than password change) if no password has been set (you are logged in, so can't do password reset via e-mail; and changing the password requires the old password)
• API access with API tokens does not work correctly (ignores the role/user of the token, instead uses the user from the header)
• How to handle not existing users
  • if this is being used for SSO purposes, one probably doesn't want to create every LDAP/SSO user manually. This probably needs a custom authenticator (?) that creates non-existing users from this header
• currently everybody can set the header. some additional checks should be implemented, e.g. whether the accessing IP is a authorized reverse proxy
• if the security.yaml should be directly edited by users, or whether there should be some different off-by-default way to enable additional authentication methods (maybe similar to SAML?)