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.
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).