[0.14.0 Beta 2]: Proxy auth not working

[miguelangel-nubla]

Describe the problem you are having

It works fine with native auth, but as soon as I set the mode to proxy, Frigate behaves as if no auth is configured.
It shows Current User: anonymous on the UI and nothing in logs about auth or any error.

Steps to reproduce

In a working native auth installation change the auth mode to proxy.

Version

0.14.0-bccffe6

Frigate config file

auth:
  mode: proxy
  header_map:
    user: x-forwarded-user

Relevant log output

Nothing relevant even with debug logging.

Operating system

Other

Install method

Docker CLI

Network connection

Wired

Camera make and model

NA

Any other information that may be helpful

No response

[NickM-27]

It works fine with native auth, but as soon as I set the mode to proxy, Frigate behaves as if no auth is configured.

that is exactly how it is supposed to work. Proxy auth means your proxy is providing the auth

[miguelangel-nubla]

This is conceptually what I have in mind, simplifying and removing the explicit proxy mode.

Configuration:

auth:
  # Optional: Reset the admin user password on startup (default: shown below)
  # New password is printed in the logs
  reset_admin_password: False
  # Optional: Cookie to store the JWT token for native auth (default: shown below)
  cookie_name: frigate_token
  # Optional: Set secure flag on cookie. (default: shown below)
  # NOTE: This should be set to True if you are using TLS
  cookie_secure: False
  # Optional: Session length in seconds (default: shown below)
  session_length: 86400 # 24 hours
  # Optional: Refresh time in seconds (default: shown below)
  # When the session is going to expire in less time than this setting,
  # it will be refreshed back to the session_length.
  refresh_time: 43200 # 12 hours
  # Optional: Number of hashing iterations for user passwords
  # As of Feb 2023, OWASP recommends 600000 iterations for PBKDF2-SHA256
  # NOTE: changing this value will not automatically update password hashes, you
  #       will need to change each user password for it to apply
  hash_iterations: 600000
  # Optional: Rate limiting for login failures to help prevent brute force
  # login attacks (default: shown below)
  # See the docs for more information on valid values
  failed_login_rate_limit: None
  # Optional: Allowed trusted proxies.
  reverse_proxy:
    - edge-proxy:
        secret: long-secure-private-secret1
        # Mapping of headers received from the proxy (default: shown below)
        header_map:
          # Used for rate limiting.
          client: x-forwarded-for
          # If no valid user header is received the request will be handled by regular auth.
          user: x-forwarded-user
        # Optional: URL where to redirect the user for logging out in the
        # downstream reverse proxy.
        # Only for clients correctly authenticated by headers (default: shown below)
        logout_url: /api/logout

Requests to the authenticated endpoint 8080 will always be handled with native authentication, except under the following conditions:

• The X-Secret-Token header matches the token specified in auth.reverse_proxy.[name].secret.
• An additional user header is received, as configured, and is valid.

These conditions override the native authentication. Invalid requests will receive a 401 Unauthorized HTTP response code and will be redirected to the login page to allow simpler use cases to work.

[blakeblackshear]

The vast majority of users aren't going to care about this setting because their reverse proxy sits on the same internal docker network as frigate. This is what I had in mind.

You still need a mode because not all proxies support passing a user down in a header. You can't assume you need to enforce native auth in that situation.

auth:
  mode: proxy
  proxy:
    authentication_method: None # defaults to None and available options are None and shared_secret
    shared_secret: <secret_value> # it needs to be possible to pass this with a docker secret or env var
    header_map:
      user: x-forwarded-user
    logout_url: /api/logout

Rate limiting is only implemented on the login url, and I don't want to make changes to that along with this.

I can't say I have personally seen other self hosted projects implement this pattern. If you have seen them, I would appreciate you listing some before it's implemented so we can check the implementation against others.

[miguelangel-nubla]

The vast majority of users aren't going to care about this setting because their reverse proxy sits on the same internal docker network as frigate. This is what I had in mind.

Exactly, I am one of those users, and I don't want other services in my network to be able to access/intercept frigate connections.
That is the whole point of all this reverse-proxy to upstream server security.

Also what about Home Assistant users? Those are very likely to not be on the same machine. This enables the frigate proxy addon to solve that use case with just a header, with all the options to use/not use user based access for those who want it.

I just want a Frigate instance that I cannot query from anywhere (internal or external network) but the authorized services.
I want to decide who sees my cameras, even on the internal network.

You still need a mode because not all proxies support passing a user down in a header.

No, if you want native auth, point the reverse proxy to 8080. With or without another external proxy auth. If you don't need native auth you point it to 5000 just like until now. With or without another external proxy auth.
This covers every use case.
What is the point of having a unauthenticated port (5000) and a authenticated port (8080) if the auth port is sometimes not protected (proxy mode)? Why the redundancy and the extra complexity for no real benefit?

Rate limiting is only implemented on the login URL, and I don't want to make changes to that along with this.

Sure, that is just fine. But you need the client IP for requests coming from reverse proxy. Otherwise everyone gets blocked.

I can't say I have personally seen other self hosted projects implement this pattern. If you have seen them, I would appreciate you listing some before it's implemented so we can check the implementation against others.

I don't know exactly which part are you referring to with pattern. I will answer generally, let me know if I missed the point of the question.

If you are referring to passing a secret to a server in order to allow the server to identify the middleman, every service that requires you to use API keys usually does this. They just call it API key.

The usual way this is done for reverse proxies is with those simple "checks" we discussed earlier that "offer no real security". That is because it is expected to use them in conjunction with proper firewall rules and proper network separation.
I agree everything has to be done just right for those "checks" to be useful, but those implementations fully rely on those checks, rejecting everything else, and do not make sense without them.

Once you stated those checks are of "no real security value", the next step is encryption and mutual auth. Everyone that does this jump for these use cases goes directly to mTLS or similar because it can work with multiple peers, and be configured in a way that you don't have to touch every server to add/remove a single point, and instead rely on PKI. Examples:

• NGINX example. Step-ca is great for easing things up.
• Traefik version

Doing it with a secret is the same pattern, but simplified in order to not require a PKI, which is way overkill for Frigate specially because Frigate instances are not expected to be scaled horizontally.

[blakeblackshear]

No, if you want native auth, point the reverse proxy to 8080. With or without another external proxy auth. If you don't need native auth you point it to 5000 just like until now. With or without another external proxy auth.
This covers every use case.

It doesn't cover the use case where all I want is for Frigate to recognize my user so it can be displayed in the UI and ultimately used for RBAC. I don't want to configure a secret_token, because I'm not worried about other containers in my docker compose making roque queries to Frigate. I guess we could apply the header_map regardless of port before bypassing the remaining authentication logic since it doesn't actually have anything to do with authentication and that would result in a clean split where 8080 requires either a secret_token or a valid JWT token and 5000 doesn't do any auth checks.

Sure, that is just fine. But you need the client IP for requests coming from reverse proxy. Otherwise everyone gets blocked.

You will find that X-Forwarded-For is already parsed and identifies the client ip by skipping trusted proxies. The header name just isn't customizable.

[miguelangel-nubla]

No, if you want native auth, point the reverse proxy to 8080. With or without another external proxy auth. If you don't need native auth you point it to 5000 just like until now. With or without another external proxy auth.
This covers every use case.

It doesn't cover the use case where all I want is for Frigate to recognize my user so it can be displayed in the UI and ultimately used for RBAC. I don't want to configure a secret_token, because I'm not worried about other containers in my docker compose making roque queries to Frigate.

So you are talking about a use case where you already have set a custom dynamic header for sending the user.
Just add another header with value X-Secret-Token=hello or whatever you want to call it. Done, use case covered.

I guess we could apply the header_map regardless of port before bypassing the remaining authentication logic since it doesn't actually have anything to do with authentication

I don't understand why you would want to do that. Port 5000 does not do auth, and does not do proxy or header parsing, just like right now.
Port 8080 does both, taking the user from header_map if wanted, which is certainly authentication.

and that would result in a clean split where 8080 requires either a secret_token or a valid JWT token and 5000 doesn't do any auth checks.

You are mixing things up, I suggested port 8080 always requires auth (frigate knows the user), either from header from reverse proxy or native auth.
You can have another independent auth on the reverse proxy and not send the header if you wanted. Or just not have it.

Sure, that is just fine. But you need the client IP for requests coming from reverse proxy. Otherwise everyone gets blocked.

You will find that X-Forwarded-For is already parsed and identifies the client ip by skipping trusted proxies. The header name just isn't customizable.

That does not make any sense. You have to trust the header, or else in setups without reverse proxy any client can send its own "simulated IP" and the rate limit will not apply to it. That is the whole point of needing to trust proxies.