Files
wild-central/internal/authelia/TODO.md
Paul Payne d796a79f79 Add Authelia as centralized authentication and OIDC provider
Authelia runs as a managed native service on Wild Central, providing
two integration patterns for network services:

- Forward-auth via HAProxy for apps without native SSO (Lua auth-request
  script intercepts requests, redirects unauthenticated users to login portal)
- OIDC provider for apps with native support (Gitea, Grafana, etc.)

Backend: new internal/authelia/ package with service manager, config
generation, file-based user management (argon2id), and OIDC client
management. API endpoints for status, config, users CRUD, and OIDC
clients CRUD.

HAProxy: config generator extended with lua-load, auth-request
directives, and Authelia backend. Auth directives scoped to session
cookie domain — only subdomains of the auth portal's parent are
eligible for forward-auth.

Frontend: Authentication page with enable/disable, user management,
OIDC client management (add/edit/delete), and protected domains
toggles. Advanced subsystem page for raw config view. Dashboard
service card and sidebar entries.
2026-07-12 11:47:37 +00:00

3.5 KiB

Authelia Packaging TODO

These steps must be added to the postinst script (wild-cloud/dist/debian/DEBIAN/postinst) when packaging Wild Central for distribution.

Install Authelia

if ! command -v authelia &>/dev/null; then
    curl -fsSL https://apt.authelia.com/organization/signing.asc | \
        gpg --dearmor -o /usr/share/keyrings/authelia-archive-keyring.gpg
    echo "deb [signed-by=/usr/share/keyrings/authelia-archive-keyring.gpg] \
        https://apt.authelia.com/integration/apt/repo/stable/debian debian main" \
        > /etc/apt/sources.list.d/authelia.list
    apt-get update -qq
    apt-get install -y authelia
fi

Install HAProxy Lua scripts

mkdir -p /etc/haproxy/lua
curl -fsSL -o /etc/haproxy/lua/haproxy-auth-request.lua \
    https://raw.githubusercontent.com/TimWolla/haproxy-auth-request/main/auth-request.lua
curl -fsSL -o /etc/haproxy/lua/haproxy-lua-http.lua \
    https://raw.githubusercontent.com/haproxytech/haproxy-lua-http/master/http.lua
apt-get install -y lua-json

Systemd service override

mkdir -p /etc/systemd/system/authelia.service.d
cat > /etc/systemd/system/authelia.service.d/wild-central.conf << EOF
[Service]
ExecStart=
ExecStart=/usr/bin/authelia --config /var/lib/wild-central/authelia/configuration.yml
EOF
systemctl daemon-reload

Data directory

mkdir -p /var/lib/wild-central/authelia
chown wildcloud:wildcloud /var/lib/wild-central/authelia
chmod 700 /var/lib/wild-central/authelia

Polkit rule (manages all Wild Central services, not just Authelia)

cat > /etc/polkit-1/rules.d/50-wild-central.rules << 'EOF'
polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units" &&
        subject.isInGroup("wildcloud")) {
        return polkit.Result.YES;
    }
});
EOF

Certificate Issues TODO

Problems discovered during Authelia integration that need fixing in the cert management system.

hasCertForDomain doesn't verify cert actually covers the domain

hasCertForDomain() in helpers.go checks if a PEM file exists at the expected path (e.g. payne.io.pem for wildcard coverage of auth.payne.io), but never verifies the cert's Subject/SAN actually matches. We had a *.payne.io.pem file that was actually a cert for central.payne.io — it passed the existence check but served the wrong cert at runtime, causing TLS errors.

Fix: Parse the cert and verify the SAN covers the requested domain, or at minimum check for CN=*.domain when relying on a wildcard.

Cert provisioning deploy hook can produce misnamed files

The certbot deploy hook builds an HAProxy PEM from /etc/letsencrypt/live/{cert-name}/. The cert name doesn't always match the domain (e.g. certbot may name a *.payne.io wildcard cert as payne.io). If the PEM filename doesn't match what HAProxyCertPath() expects, the cert won't be found or will be confused with a different cert.

Fix: The deploy hook or BuildHAProxyCert should name the PEM based on the cert's actual SAN, not just the certbot cert name.

UI has no "re-provision" option when cert exists but is wrong

The Certificates UI considers a cert valid if the PEM file exists and is non-empty. There's no way to re-provision if the cert covers the wrong domain or is otherwise invalid. The user had to manually delete the bad PEM to trigger re-provisioning.

Fix: Add a "Re-provision" or "Renew" action per domain in the Certificates UI, and show what domain(s) the cert actually covers (parsed from SAN).