Auto Login using Forward Authentification Header

[Christoph-87]

Before submitting this feature request I have
COMPLETE AND FILL THESE OUT

• Reviewed the documentation and verified that my feature request isn't already a feature.
• Reviewed the existing feature requests and my feature has not been requested.
• Checked the tasks taged issues and verified my feature is not covered

Please Describe The Problem To Be Solved
I am using a reverse proxy with authentification. The reverse proxy provides forward authentification.
https://doc.traefik.io/traefik/middlewares/http/forwardauth/
It would be great if an auto login could be implemented analogous to this:
causefx/Organizr#1215

Additional Information

• If the feature is accepted I'm willing to submit a PR to provide this feature
  I would be happy to do this, but I would need some advice for this.

[Christoph-87]

See this discussion: #284

[hay-kot]

I'd gladly accept a PR on this. Unfortunately, I'm not sure I can be much help in how to approach it. Happy to answer any questions you have though!

[Christoph-87]

Thanks a lot! I will read the contributors guide the next days. In the meantime I did some screenshots to explain the idea. When using authentication headers, the values are stored in environment variables. I used the docker image whoami to display them. The variables are configurable. It should be optionally be possible to configure the proxy IP for security reasons. In this case, the environment variables in the yellow box are the variables of interest. "RemoteAddr" is the IP of the proxy and "Remote-Email", "Remote-Name" and so on are the data for the user that already did a login.

I would add a box in the admin page to configure the settings.

On a web request I would compare the configured Proxy IP against "RemoteAddr" if the configured value of the Proxy IP is not "0.0.0.0" (this value I would consider as "disabled check"). If the check was possible, there has to be a lookup if there is a user with the configured environment variables with the given name or mail. If yes, the user should be treated as authenticated.

[Christoph-87]

On a second thaught it should be enough to configure it in a config file or using docker environment variables?

[hay-kot]

I'm a little confused. Does each user need to set this up, or can it be set once for the whole server? If it's once for the whole server I think an ENV variable makes sense, otherwise it would need to be added to the user database table. Also, what happens if the user doesn't exist?

[Christoph-87]

No, the value in the authentication headers will be the respective user, so this can be set once for the whole server. If the user stored in the authentication headers does not exist, the authentication header should be ignored (that is different to LDAP, the user will not be created).

[xionous]

I too would like to see this feature added.

@Christoph-87 to your point of ignoring the login if the user doesn't exist, i think this should be an option that can be enabled. The whole point of remote user auth is to act as a SSO, to work properly it needs to be able to create a user that is not there so there is a single point of configuration for users. This is the point of centralized authentication.

For example, when i create a user in LDAP and assign them to a mealie group this means my auth middleware knows to grant that user access to mealie and as such that user should have access to mealie and the middleware will pass the auth headers to mealie. So having to manually create a user that doesn't exist doesn't make sense, if that user is not supposed to be able to login then the middleware would not let them get to it in the first place. And because the headers can pass the groups the users are in that can be used to determine the level of access they get.

E.G. a LDAP group for read only access, a LDAP group for add/edit access, and a LDAP group for admins

Some of the few reasons for this methodology is because remote-user headers should log the user in before the page finishes loading so the page can reflect the user is logged in and enabling multiple auth types at the same time can be difficult to code so having an environment variable to enable remote-user-auth so that becomes the only way to login when enabled may make things easier.

[aroberts]

I'm very interested in this as well. For those of us who will only run Mealie behind a reverse proxy with SSO, header-based auth is actually a significantly more streamlined user experience than SAML or direct LDAP - users who are already authenticated via SSO are automatically logged in upon visit. Direct LDAP connection can only handle keeping credentials in sync, but does nothing for the ergonomics of actually getting logged in.

I looked into this, and ran into a couple of problems:

• FastAPI's middleware is not as refined as django's, which already has middleware available to do this
• mealie is structured around tokens using (it looks like) nuxtjs/auth, which doesn't seem to process any login action unless initiated via user action.

Generally, the strategy is to have the app detect those headers server-side on every request, and then when rendering the response, perform a login action (creating a user locally if necessary), so that by the time the user sees the response, they are logged in (and see a logged-in render of the page they requested. It's unfortunately not clear to me how to attack this in the frameworks here, but I'm willing to give it a go if someone who knows these frameworks can shed some light here.

[lenaxia]

Honestly, I'd prefer this method over OIDC. I have multiple apps running various levels of OIDC and forward auth, and unequivocally, forward auth is superior from a microservice standpoint.

Pros:

• It does not expose ANY part of the service until auth has been completed, reducing attack surface
• It does not require extra steps (such as consent) for users, it is very natural for what people are used to
• It actually performs as SSO, unlike OIDC which requires consent before acting like SSO
• It is far simpler than OIDC, which requires multiple endpoints and handshakes, which isn't realy necessary for self hosters
• It is easier to configure, requiring only a few headers to be defined
• It can be backed by either LDAP or build in user dir
• Way easier to debug than OIDC

Cons:

• It requires a trust model that isn't enforceable (local access over LAN is always priviledged, so no docker ports or k8s services), but we're not dealing with national secrets here
• Really that it, there are very few cons to forward auth

[poperigby]

I'd be very interested in OIDC! I run an Authelia instance, and it makes it very convenient to authenticate all of my family and friends with my services.

[namelivia]

I've implemented this feature here: #2206 I'm doing the finishing touches, let me know if this works for you.

[userbradley]

Just chiming in my input here, would be best to have it as a config file option. I use cloudflare tunnels and zero trust, as well as a mix of Pritunl.

It would be preferable to be able to set a HTTP header that should designate as username

An example would be:

Setting('AUTH_CLASS', 'Grocy\Middleware\ReverseProxyAuthMiddleware');

// Options when using ReverseProxyAuthMiddleware
Setting('REVERSE_PROXY_AUTH_HEADER', 'X-Forwarded-User');

This means that if you have non-normal headers, you wont have any issues

[aroberts]

hi @michael-genson this feature is actually not available in mealie, did you intend to close this as resolved?

[michael-genson]

Apologies, I've been going through discussions and closing them. I saw a comment above about a PR that was opened but I see now that it was closed, not merged

It's re-opened now

[aroberts]

No worries, I totally understand the housekeeping. Thanks for re-opening. For posterity, I'll also note that a related request is here: #3664