Trying to get trusted header auth to work

[Atlasfreak]

Hi,
I am trying to get trusted header auth to work with authentik as the sso provider, apache with mod_auth_openidc as the proxy and running wakapi via docker compose.
The problem is I do not know why it isn't working. It could be wrong header names or I haven't configured the trusted ips correctly. With the ips I also just do not know which one to use as docker compose assigns the container to a random free network making it impossible to hardcode the gateway ip and idk if "host.docker.internal" works.

Anyone might know where the problem lies or has already managed to get trusted_header auth working with docker compose?

[muety]

Hi @Atlasfreak! Getting these three tools properly hooked up together (in Docker) indeed sounds like a non-trivial endeavor. Just a couple of thought from my side that might help you debug this:

First of all, you'll have to set WAKAPI_TRUSTED_HEADER_AUTH=true and WAKAPI_TRUSTED_HEADER_AUTH_KEY=REMOTE_USER (case-insensitive).

Then, regarding IPs: if you're running Wakapi in Docker, while Apache is running on the host directly, requests relayed from Apache will probably appear to come from the Docker network bridge's gateway address. That's 172.17.0.1 by default, you can double-check using docker inspect. If Apache is running in Docker as well, I'd recommend to create a new network (e.g. name it reverse_proxy_net and connect both containers to it. The container's IPs will then have IPs like 172.<i>.0.<j>, where i is the index of the network plus one (e.g. 2 if you only have one Docker network configured) and j is the index of the container plus one in the order you started them (e.g. 2 for the first container connected to this network). Again, you can use docker inspect for investigation.

Another issue might be the value that mod_auth_openidc passes on in the trusted auth header field. According to their docs, it's set to the concatenation of the token's sub and iss claims (like [sub]@[iss]). Wakapi, however, requires the header to contain nothing but a plain, valid Wakapi user name (e.g. muety). Apparently, you can customize (see here) the header field (using OIDCRemoteUserClaim?). So the preferred option here would be to configure a wakapi_username (or sth.) attribute for your user in Authentik and then configure the reverse proxy to use the token claim corresponding to that attribute as the value for REMOTE_USER. If that's not an option, we could think of extending Wakapi in a way that not only usernames, but also e-mail addresses are accepted for trusted header authentication.

In general, a tool that might help you debug HTTP-related problems like this is https://rbaskets.in/web, I'm using it regularly.

Hope that helps. Keep us posted.

[Atlasfreak]

Thanks for the in depth help.
I am pretty sure that the problem is the IP as docker compose always assigns a random network with a random gateway so I cannot hardcode it. In my case it is most often placed in the 192.168.x.x range and the Gateway is also always somewhere in that range but it is different everytime I reboot the container. So harcoding this is not possible.
I sadly do not have enough knowledge of docker to know how to either fix the network where wakapi is placed or if there are any variables which can be used in a compose file to get the gateway address.

[Atlasfreak]

Finally got it to work.
I set the network_mode variable to bridge so that the wakapi container would be attached to the default docker network.
Then I could set the WAKAPI_TRUST_REVERSE_PROXY_IPS to 172.17.0.1. Additionally I needed to set OIDCAuthNHeader Remote-User in the apache config.
Also you can change the value mod_auth_openidc passes to wakapi with OIDCRemoteUserClaim. I set this to sub and adjusted the wakapi username to fit the username in authentik.
Thanks again for the help @muety rbaskets did really help.
Apparently Apache never sent any Remote-User Header at all not even REMOTE_USER