Copy_header copying empty headers with Authelia

Help
1

1. The problem I’m having:

I have Caddy set up with Authelia in docker. Everything works, but I have an issue with the copy_header putting empty headers when I have Authelia set to bypass authentication if I am accessing from my LAN.

My Caddyfile:

auth.mydomain.com {
	reverse_proxy authelia:9091
}

whoami.mydomain.com {
	forward_auth authelia:9091 {
		uri /api/authz/forward-auth
		copy_headers Remote-User Remote-Groups Remote-Email Remote-Name
	}
	reverse_proxy whoami:80
}

In my Authelia config, I use this to bypass for LAN access:

access_control:
  default_policy: deny
  rules:
    - domain: '*.mydomain.com'
      networks:
        - 192.168.1.0/24
      policy: bypass

In this setup when access whoami.mydomain.com from my LAN, the headers in the copy_header directive above look like so:

Remote-Email: {http.reverse_proxy.header.Remote-Email}
Remote-Groups: {http.reverse_proxy.header.Remote-Groups}
Remote-Name: {http.reverse_proxy.header.Remote-Name}
Remote-User: {http.reverse_proxy.header.Remote-User}

When accessing from outside the bypassed net in Authelia (i.e., when I am not on my LAN and therefore have to authenticate through Authelia), they are populated with the values from Authelia like normal:

Referer: https://auth.mydomain.com/
Remote-Email: steve@mydomain.com
Remote-Groups: admins
Remote-Name: Steve
Remote-User: steve

Is there a way I can prevent this from happening? That is, just don’t put the headers in there when thy are empty?

2. Error messages and/or full log output:

There are no errors or messages in the logs when this happens

3. Caddy version:

v2.8.4 h1:q3pe0wpBj1OcHFZ3n/1nl4V4bxBrYoSoab7rL9BMYNk=

4. How I installed and ran Caddy:

a. System environment:

Docker install on debian 10 with image caddy:latest.

b. Command:

docker compose up

:slight_smile:

c. Service/unit/compose file:

services:
  caddy:
    image: caddy:latest
    container_name: caddy
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - $PWD/Caddyfile:/etc/caddy/Caddyfile
      - $PWD/site:/srv
      - $PWD/caddy_data:/data
      - $PWD/caddy_config:/config
      
  authelia:
    container_name: 'authelia'
    image: 'authelia/authelia'
    restart: 'unless-stopped'
    volumes:
      - $PWD/authelia_config:/config

  whoami:
    container_name: 'whoami'
    image: 'traefik/whoami'
    restart: 'unless-stopped'

d. My complete Caddy config:

shown above

5. Links to relevant resources:

none

2

Hmm yeah that’s unfortunate. I’ll try to implement a fix for forward_auth to not do that.

But for now as a workaround you can use the long form forward_auth (Caddyfile directive) — Caddy Documentation but change the request_header part to read like this:

@Remote-User not vars {rp.header.Remote-User} ""
request_header @Remote-User Remote-User {rp.header.Remote-User}
@Remote-Groups not vars {rp.header.Remote-Groups} ""
request_header @Remote-Groups Remote-Groups {rp.header.Remote-Groups}
@Remote-Email not vars {rp.header.Remote-Email} ""
request_header @Remote-Email Remote-Email {rp.header.Remote-Email}
@Remote-Name not vars {rp.header.Remote-Name} ""
request_header @Remote-Name Remote-Name {rp.header.Remote-Name}

This is annoying boilerplate, but what this does is use a matcher on each header to check that the value is not empty before applying it to the request.

1 Like
3

I implemented a fix here:

1 Like
4

Thanks! I’ll see if I can check it out this weekend. As a workaround, I used a couple of handles and matchers to only call forward_auth for external IPs. Not sure which is more secure, if any

5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.