Belajar Authelia - Caddy Integration

#Pendahuluan

Di episode 14 kalian memasang middleware ForwardAuth di Traefik lewat Docker labels. Kali ini kita mencoba proxy yang menempatkan kesederhanaan sebagai prinsip: Caddy. Caddy dikenal dengan dua keunggulan yang langka: konfigurasi yang sangat ringkas (Caddyfile), dan HTTPS otomatis lewat Let's Encrypt tanpa satu baris pun untuk urusan sertifikat.

Untuk forward authentication, Caddy menyediakan direktif bawaan forward_auth. Ia melakukan hal yang sama seperti auth_request NGINX dan middleware forwardAuth Traefik: mengirim sub-request ke Authelia, lalu meneruskan atau menolak permintaan berdasarkan responsnya. Bedanya, sintaksnya jauh lebih ringkas — sering kali cukup empat hingga enam baris di dalam blok situs.

Analogi: kalau NGINX memberi kalian panel kontrol dengan seratus saklar, dan Traefik memberi kalian katalog label yang bisa ditempel, maka Caddy memberikan satu tombol besar bertuliskan "amankan". Sedikit lebih sedikit kontrol — tetapi jauh lebih sedikit yang bisa salah.

#Struktur Caddyfile: Portal dan Aplikasi

Caddyfile terdiri dari blok-blok situs. Contoh dasar dengan portal Authelia dan satu aplikasi yang dilindungi:

Caddyfile — portal dan aplikasi

# Portal Authelia.
auth.example.com {
    reverse_proxy authelia:9091
}
 
# Aplikasi yang dilindungi.
nextcloud.example.com {
    forward_auth authelia:9091 {
        uri /api/authz/forward-auth
        copy_headers Remote-User Remote-Groups Remote-Email Remote-Name
    }
 
    reverse_proxy nextcloud:80
}

Mari bedah:

• reverse_proxy authelia:9091 pada blok portal — Authelia sendiri adalah layanan biasa; tidak perlu middleware khusus untuk menjangkaunya.
• forward_auth authelia:9091 — Caddy mengirim sub-request ke Authelia setiap kali ada permintaan ke situs ini.
• uri /api/authz/forward-auth — endpoint verifikasi yang dipanggil. Ini menentukan alur ForwardAuth Authelia, lengkap dengan evaluasi access control rules.
• copy_headers Remote-User Remote-Groups Remote-Email Remote-Name — menyalin header identitas dari respons Authelia ke permintaan yang diteruskan ke aplikasi. Inilah jembatan Trusted Header SSO.

Yang menarik: Caddy secara default tidak mempercayai header dari proxy lain dan membersihkan header yang berpotensi dipalsukan. Ini perilaku aman bawaan — kalian hanya perlu menambahkan direktif trusted_proxies jika ada lapisan proxy lain di depan Caddy.

#Peran HTTPS Otomatis

Satu hal yang membuat Caddy istimewa di konteks Authelia: setiap blok situs otomatis mendapat sertifikat TLS dari Let's Encrypt. Tidak ada file ssl.conf, tidak ada renewal manual, tidak ada baris listen 443.

Kenapa ini penting untuk Authelia? Karena Authelia adalah sistem berbasis cookie sesi yang aman hanya di atas HTTPS. Cookie Secure (yang kita bahas di episode 7) tidak akan terkirim lewat HTTP polos, dan redirect antara portal dan aplikasi dijamin aman karena kedua belah pihak sudah HTTPS. Dengan Caddy, syarat itu terpenuhi hampir gratis.

Jika kalian mengetes di lab tanpa domain publik, Caddy tetap bisa melayani dengan CA internal — misalnya dengan direktif global tls internal untuk sertifikat lokal yang self-signed, cocok untuk jaringan rumah.

#Penyesuaian URL Authelia di Proxy

Secara default, saat permintaan ditolak, Caddy melempar redirect ke portal Authelia. Nilai URL portal diambil dari konfigurasi sesi Authelia (session.cookies[].authelia_url). Ini pendekatan paling rapi — satu sumber kebenaran di sisi Authelia.

Namun untuk kebutuhan tertentu, kalian bisa menimpa lewat parameter query pada direktif uri:

Caddyfile — authelia_url eksplisit

nextcloud.example.com {
    forward_auth authelia:9091 {
        uri /api/authz/forward-auth?authelia_url=https://auth.example.com/
        copy_headers Remote-User Remote-Groups Remote-Email Remote-Name
    }
 
    reverse_proxy nextcloud:80
}

Meski didukung, dokumentasi resmi menyarankan konfigurasi URL di sisi Authelia daripada menimpa di proxy — dengan satu sumber kebenaran, tidak ada dua tempat yang bisa tidak sinkron.

#Keamanan: Tutup Cookie Sesi dari Backend

Satu pertimbangan yang sering terlewat: setelah login, browser mengirim cookie sesi Authelia ke semua subdomain yang cocok — termasuk aplikasi yang dilindungi. Aplikasi itu sebenarnya tidak perlu melihat cookie sesi; ia hanya perlu header Remote-User.

Untuk aplikasi yang sangat sensitif, cookie sesi bisa dihapus dari header Cookie sebelum diteruskan:

Caddyfile — menutup cookie sesi dari backend

nextcloud.example.com {
    forward_auth authelia:9091 {
        uri /api/authz/forward-auth
        copy_headers Remote-User Remote-Groups Remote-Email Remote-Name
    }
 
    reverse_proxy nextcloud:80 {
        header_up Cookie "authelia_session=[^;]+" "authelia_session=_"
    }
}

Praktik ini memastikan bahwa meskipun aplikasi berhasil disusupi, ia tidak bisa membajak sesi Authelia pengguna. Defense in depth yang murah.

#Testing Integrasi

1. Pastikan kedua blok situs merespons HTTPS dengan benar — auth.example.com menampilkan portal, nextcloud.example.com mengarahkan ke portal.
2. Login dan selesaikan MFA; kalian harus kembali ke Nextcloud tanpa login kedua.
3. Periksa header yang tiba di aplikasi: Remote-User harus berisi username, Remote-Groups berisi daftar grup.
4. Jika ada yang keliru, periksa log Caddy dan Authelia — keduanya akan mencatat jalur sub-request secara jelas.

#Penutup

Episode ini mengintegrasikan Authelia dengan Caddy: direktif forward_auth sebagai sub-request verifikasi, direktif uri yang menunjuk ke /api/authz/forward-auth, penyalinan identitas lewat copy_headers, HTTPS otomatis yang mengamankan cookie sesi, hingga praktik opsional menutup cookie sesi dari backend.

Caddy menunjukkan bahwa forward authentication tidak harus rumit — sintaks minimal, keamanan yang baik secara default, dan satu hal yang bisa kalian serahkan sepenuhnya: TLS. Di episode 16, kita melihat proxy klasik yang sering dipakai di infrastruktur skala menengah: HAProxy, dengan pendekatan berbasis ACL dan Lua. Sampai jumpa!