Reverse proxy header authentication

Feature Discussion
1

I have recently discovered Authelia, which works with a reverse proxy (Traefik, in my case) to provide authentication and authorisation.

If an application supports it, it’s very elegant - the reverse proxy takes care of all the authentication and session data, and the application just needs to pay attention to HTTP headers (Remote-User, primarily) to know who is currently logged in.

Would be great if reverse proxy header authentication could be added to the roadmap!

1 Like
2

There’s been an attempt in the past to add that here and here. Unfortunately that has gone stale, if anyone wants to pick it up I’m all open for it.

3

Sorry, I think I might have have caused confusion by describing the auth method incorrectly.

“Forward auth” is what I’m after. This can be provided by Authelia or Authentik. Those PRs were for Pomerium, which works differently.

2 Likes
4

So the Vikunja API would only need to verify if the headers Authelia / Authentik sends through the proxy are correct and use the user provided in them?

1 Like
5

That’s correct. The idea is that the service (in this case Vikunja) is never exposed to the Internet so it can implicitly trust the headers being passed to it by Traefik/Authelia. APIs are an exception - they tend to handle authentication differently e.g. with a key or token so they can bypass Authelia.

With regards to user management, I’ve seen two ways of it being handled. One way is for the service to automatically create a new user if it receives a Remote-User header it has never seen before. The other way is to require an account to be manually created first.

1 Like
6

I am also a big fan of Authelia acting as the Authentication layer for a lot of software. Currently, my Docker-swarm setup is that all apps sit behind Traefik, Authelia is the de-facto authenticator together with OpenLDAP and the apps do not need to use their native authentication mechanisms.
Firefly authentication options are a good example of this.

Firefly III supports RFC 3875 which means your users can authenticate using the REMOTE_USER header. When you enable this method, an authentication proxy in front of Firefly III MUST be set up to care of the user’s login and authentication. This lets you to use advanced login methods like hardware tokens, single sign-on, fingerprint readers and more. Once the authentication proxy says you’re logged in, it will forward you to Firefly III.

A very popular tool that can do this is Authelia.

1 Like
7

Hi. Sorry for bumping this old topic. I am also very interested in this kind of proxy auth. To add a little more detail, the perfect proxy auth feature for me would work like this:

  1. Start the app with additional environment variables:
  • containing the name of the initial admin user (e.g. admin=admin_user)
  • enabling proxy auth (e.g. proxy_auth=true)
  • setting the key of the http header that contains the username (e.g. auth_header=X-Authenticated-User)
  1. Configure the reverse proxy to authenticate incoming requests in any way you like.
  2. Let the reverse proxy set X-Authenticated-User to the authenticated username on every request.
  3. The app treats the requests as if they belong to the appropriate user session.
  4. Bonus: if the app does not know the username, it creates a new user with that name.

Here are some examples of apps that feature proxy authentication: LinkDing, Navidrome.

I’d be really greatful for this feature. Should also be relatively simple to add, right?