qBittorrent icon indicating copy to clipboard operation
qBittorrent copied to clipboard

Single Sign-On with Traefik for WebUI

Open rourke opened this issue 4 years ago • 6 comments

Please provide the following information

qBittorrent version and Operating System

qBittorrent v4.2.5 Web UI (64-bit) on Ubuntu Server 20.04 (docker)

If on linux, libtorrent-rasterbar and Qt version

Qt: | 5.14.2 Libtorrent: | 1.2.6.0 Boost: | 1.72.0 OpenSSL: | 1.1.1g zlib: | 1.2.11

What is the problem

I want to skip the WebUI authentication, but not for the /api/ endpoint. This requires some explanation. Currently my settings look like this:

image

172.18.0.0/24 is my docker subnet. Since I'm using Traefik to put qBittorrent behind a subdomain the RemoteAddr http header will always be that of Traefik (in my case 172.18.0.2) and so within this subnet. So I will always be logged in into qBittorrent, which is perfect because the authentication is handled by an external application called Authelia anyway. So basically I go to qbittorrent.domain.com -> get redirected to Authelia login page -> login -> get redirected back to qbittorrent.domain.com -> I'm logged into qBittorrent. It's a very smooth Single Sign-On experience.

However I just created a Traefik bypass for the /api/ endpoint, which means no Authelia authentication is needed to access the qBittorrent API. This is ideal for apps like nzb360 from where you can maintain your torrents. But because of the configured subnet qBittorrent accepts every request coming in, even if a wrong username/password is provided. This is of course very dangerous.

I see a couple of solutions:

  • qBittorrent could look at custom headers to log a user in. Authelia provides a Remote-User and a Remote-Groups header. qBittorrent could match against this to log the user in. I could even create a new one i.e. qBittorrentAuth=true to make it more practical.
  • Ignore this bypass authentication setting for the API endpoint. Or at least make this a configurable option. This might not be a good solution because the WebUI makes use of the API as well.

Perhaps there are other solutions which I overlooked, but I can't quite figure out any because the authentication and security settings don't have any documentation. At least not that I could find.

rourke avatar Aug 05 '20 18:08 rourke

I would also like to see this happen. I'm utilizing authentik for SSO and auth on selfhosted applications on my network. The ability to better integrate qbittorrent into this system for enhanced security when accessed externally would be great.

swallace17 avatar Jun 19 '22 04:06 swallace17

Same here. Traefik + Authelia, now I have to login to qbittorrent again after login to Authelia. So anyone any process yet?

geeklihui avatar Jul 18 '22 02:07 geeklihui

A decent solution would be to have an option to only enable qb built-in authentication on the /api endpoint. That way we can protect the UI with Authelia/Authentik/Whatever and bypass auth for the /api endpoint which is already protected by qb built-in auth. This pattern is pretty common with Radarr/Sonarr/Sabnzbd and other software.

onedr0p avatar Aug 06 '22 19:08 onedr0p

Isn't it possible with Traefik routers and rules?

https://doc.traefik.io/traefik/routing/routers/

ben-ba avatar Sep 26 '22 21:09 ben-ba

Isn't it possible with Traefik routers and rules?

https://doc.traefik.io/traefik/routing/routers/

Not that I can think of, because the issue is on QBit side : ie qbit authentication is binary, either requires it for all paths, or for none, that's the (main) issue here. So routers and rules wouldn't help you. I Qbit allowed setting the user via an HTTP header, then yes, it would be possible.

foux avatar May 22 '23 06:05 foux