[FEATURE] Access controls for non-containerized apps

[mitchellkellett]

Is your feature request related to a problem? Please describe.
I'd like to be able to protect non containerised, but proxied apps, by using groups from my oidc provider. For example, my solar system has a page where I can view the outputs etc, but has no authentication. So I proxy it through NPM (ie https://solar.example.com) and I'd like to have it protected with Tinyauth.

Describe the solution you'd like
A way to protect non containerised proxied apps by using groups. I'm thinking that we could add something like proxy_set_header X-Tinyauth-Groups: My-App-Users to the NPM config like in the below.

Describe alternatives you've considered
Currently, the only option I can see is to have it require an active account in my oidc provider because I'm not able to apply labels like I do to my containerised applications.

Additional context

# Root location
location / {
  # Pass the request to the app
  proxy_pass          $forward_scheme://$server:$port;
  
  # Tinyauth auth request
  auth_request /auth;
  error_page 401 = @tinyauth_login;
  
  # Pass the auth request headers
  auth_request_set $tinyauth_remote_user $upstream_http_remote_user;
  proxy_set_header remote-user $tinyauth_remote_user;
  auth_request_set $tinyauth_remote_email $upstream_http_remote_email;
  proxy_set_header remote-email $tinyauth_remote_email;
  auth_request_set $tinyauth_remote_name $upstream_http_remote_name;
  proxy_set_header remote-name $tinyauth_remote_name;
  auth_request_set $tinyauth_remote_groups $upstream_http_remote_groups;
  proxy_set_header remote-groups $tinyauth_remote_groups;
  
  # Standard proxy headers (these were missing)
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header X-Forwarded-Scheme $scheme;
  
  # Additional proxy settings for better compatibility
  proxy_http_version 1.1;
  proxy_set_header Connection "";
  proxy_cache_bypass $http_upgrade;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
}

# Tinyauth auth request
location /auth {
  # Pass request to tinyauth
  proxy_pass http://tinyauth-server-1:3000/api/auth/nginx;
  
  # Pass the request headers
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header X-Forwarded-Host $http_host;
  proxy_set_header X-Forwarded-Uri $request_uri;

  # Pass required groups
  proxy_set_header X-Tinyauth-Groups: My-App-Users
}

# Tinyauth login redirect
location @tinyauth_login {
  return 302 https://auth.example.com/login?redirect_uri=$scheme://$http_host$request_uri;
}

[steveiliop56]

Hello,

This is an amazing idea! It can be included in v4 alongside with the label refactor.

[mattberry1979]

I'm trying to accomplish something similar: using TinyAuth with Caddy for reverse-proxied non-containerized apps. TinyAuth is easy to integrate with a simple Caddy config. But there's no way to tell TinyAuth to require membership of a different group for each app (as far as I can tell).

I'd rather not code access logic into the reverse proxy config. It seems better to have TinyAuth require users to be members of either (i) a group that matches the FQDN of the app, or (ii) a superuser group. In other words, match the user's groups returned by the OIDC or LDAP provider with the app domain in their original request passed by the reverse proxy.

For example, membership of group app1.example.com group would grant access to the app with same FQDN. In my setup, these group memberships could easily be set either in LLDAP or in Pocket ID.

[steveiliop56]

Added in #337, you will be able to do proxy_set_header tinyauth-apps-myapp-users-allow user1,user2 and Tinyauth will use it. Keep in mind that it will need a trusted proxies configuration option that will be added in the next pull request. Tracking issue is #338