Support for Auth proxy

[yegle]

Prerequisites

• [x] I am running the latest version
• [x] I checked the documentation and found no answer
• [x] I checked to make sure that this issue has not already been filed

Problem Description

I'm running pomerium.io as the reverse proxy to Adguard Home's web UI. It would be great if Adguard Home web UI can support identity-aware proxy like Pomerium.

Proposed Solution

When the incoming HTTP request contains an X-Foo-Bar: username header, Adguard Home web UI should treat it as an authenticated HTTP request as if username is logged in.

The header X-Foo-Bar should be configurable.

(See the doc on Grafana's auth proxy support: https://grafana.com/docs/grafana/latest/auth/auth-proxy/)

Alternatives Considered

An option to disable authentication completely, and relying on the reverse proxy to authenticate the access to the web UI.

Additional Information

[ameshkov]

Thanks for the feature request, it makes sense indeed!

An option to disable authentication completely, and relying on the reverse proxy to authenticate the access to the web UI.

This is possible, removing all users from AdGuardHome.yaml disables authentication. So you can simply replace users with users: []

[yegle]

Thanks for the workaround! Disabling authentication makes sense if you already have a reverse proxy restricting access.

Now think about it I think supporting auth proxy may not make a lot of sense. From what I can see, logged in user doesn't have a way to configure per-user settings. Supporting auth proxy only makes sense if most people would have more than 1 users, otherwise one may just disable authentication and use auth proxy and not passing the username to AdGuard Home's web UI.

[Generator]

@ameshkov won't disabling authentication also leave the API without authentication? would be better disable login page but leave auth on for API?

[ihipop]

@Generator

@ameshkov won't disabling authentication also leave the API without authentication? would be better disable login page but leave auth on for API?

https://github.com/AdguardTeam/AdGuardHome/blob/db52f7a3aca54dcea286a0b151fcca38b0fb8e8b/internal/home/auth.go#L547-L555

BasicAuth is supported , you can set up basic auth via your reserve proxy when connecting to the backend and also keep ADG's authentication at the sametime

[LeVraiRoiDHyrule]

Hi, I am looking if there is a way to disable authentication only on the web UI as I have proxy auth with Authentik. Is that doable without removing auth in the API ?

[ihipop]

I've told you, use basic auth in your reserve proxy when proxy to Adguard home, it's just as simple as set a header in your reserve proxy engine

On Fri, Dec 29, 2023, 5:31 AM LeVraiRoiDHyrule @.***> wrote:

Hi, I am looking if there is a way to disable authentication only on the web UI as I have proxy auth with Authentik. Is that doable without removing auth in the API ?

[LeVraiRoiDHyrule]

It works perfectly with basic auth ! Thanks !

[terafirmanz]

It works perfectly with basic auth ! Thanks !

@LeVraiRoiDHyrule Did you do anything in particular to get it working in Authentik? I added a group and set attributes, then enabled basic-auth on the provider but I still get the login page. All other apps using basic auth work perfectly.

edit: for anyone who has the same. In the Authentik provider you have to disable "Intercept header authentication" but leave "Send HTTP-Basic Authentication" enabled with your attribute names.

[cvvs]

I've been looking at the auth code. I think if the auth field of the homeContext struct were an interface instead of an Auth struct, then it would be fairly simple to replace old or create new authentication mechanisms.

I tried making homeContext generic, but the declaration var globalContext homeContext in home.go makes that a bit challenging. I believe one must specify a concrete type, so there's no easy way, that I can see, to leverage generics to specify the auth type at runtime. I don't use generics very often, so please correct me if I'm wrong.

I'm working on a generic or interface solution to make authentication and authorization a bit more pluggable since have a need for OIDC and OAuth2 auth.

Note: I know I can use the no-auth work-around, but that's not ideal for obvious reasons.

[ainar-g]

@cvvs, feel free to make a fork.

It is unlikely that we'll merge the changes from your hypothetical fork, though, because we're currently in the process of redesigning the authentication process and make it more pluggable in the codebase.

[cvvs]

I'm looking forward to using it when it's ready. Thanks!