Belajar Authelia - Access Control Rules

#Pendahuluan

Di episode 5, kalian sudah menyiapkan authentication backend: menentukan siapa yang boleh masuk dengan password hash berargon2id, baik dari file users_database.yml maupun LDAP/Active Directory. Sekarang Authelia sudah bisa menjawab pertanyaan pertama: siapa kamu? Tinggal satu pertanyaan lagi yang sama pentingnya: kamu boleh masuk ke mana?

Jawabannya ada di section access_control, jantung authorization di Authelia. Analoginya begini: authentication seperti penjaga di pintu masuk gedung yang memeriksa kartu identitas kalian, sedangkan authorization adalah daftar ruangan mana saja yang boleh kalian masuki setelah lolos pemeriksaan. Di episode ini kalian akan membangun daftar itu secara presisi, mulai dari jaring pengaman default_policy, anatomi setiap aturan, sampai urutan evaluasi yang sering jadi sumber bug halus.

#default_policy: Jaring Pengaman Terakhir

Bayangkan sebuah gedung di mana setiap pintu terkunci secara default. Kalian hanya bisa masuk ke ruangan yang memang sengaja dibuka untuk kalian. Itulah filosofi default_policy: kebijakan yang berlaku ketika tidak ada aturan yang cocok dengan permintaan.

Ada empat nilai yang bisa kalian pakai:

deny: blokir semua akses. Rekomendasi utama Authelia.
bypass: izinkan tanpa autentikasi sama sekali.
one_factor: butuh password saja.
two_factor: butuh password plus metode kedua (TOTP, WebAuthn, atau Duo).

Jaring pengaman deny

access_control:
  default_policy: deny
  rules: []

Important

Selalu mulai dari default_policy: deny (fail closed). Lebih aman mengunci semua pintu lalu membuka yang memang perlu, daripada membuka semua lalu menutup satu-satu. Kesalahan konfigurasi pada mode fail open bisa mengekspos layanan kalian tanpa autentikasi.

Dengan pola ini, setiap layanan baru yang kalian tambahkan otomatis terkunci sampai kalian menulis aturan eksplisit untuk membukanya. Tidak ada akses yang terjadi kebetulan.

#Anatomi Sebuah Aturan

Setiap entri dalam rules adalah daftar kriteria plus satu policy. Semua kriteria yang ada harus cocok (logika AND), baru kemudian policy diterapkan. Kriteria yang tersedia: domain, domain_regex, subject, resources, methods, networks, dan query.

#domain dan domain_regex

Kriteria paling dasar: mencocokkan nama domain yang diminta. domain mendukung wildcard, sedangkan domain_regex memakai ekspresi reguler gaya RE2 (dialek Go) untuk pola yang lebih liar.

    - domain: "*.example.com"
      policy: one_factor

Aturan pertama cocok dengan semua subdomain example.com. Aturan kedua cocok dengan domain seperti dev-12.example.com, berguna saat kalian punya banyak environment yang dinamis.

#subject: Siapa yang Berlaku

subject memfilter berdasarkan pengguna atau grup, dengan prefix user: atau group:. Authelia mendukung logika AND/OR: list di dalam list berarti AND, list di luar berarti OR.

Kombinasi subject AND dan OR

    - domain: "dev.example.com"
      resources: ["^/groups/dev/.*$"]
      subject:
        - ["group:dev", "user:john"]
        - "group:admins"
      policy: two_factor

Aturan di atas cocok jika pengguna adalah member grup dev dan bernama john, atau jika pengguna adalah member grup admins. Di luar kedua kombinasi itu, aturan tidak cocok.

#resources, methods, dan query

resources: mencocokkan path dan query permintaan dengan regex gaya RE2. Contoh ^/api/.*$ cocok dengan semua path yang diawali /api/.
methods: membatasi ke method HTTP tertentu seperti GET, POST, atau DELETE. Berguna misalnya membiarkan GET terbuka tetapi POST butuh autentikasi.
query: kriteria tingkat lanjut untuk memeriksa parameter query dengan operator equal, not equal, present, absent, pattern, dan not pattern. Untuk kebutuhan dasar, dokumentasi resmi menyarankan memakai resources saja.

#networks: Dari Mana Asal Permintaan

networks mencocokkan alamat IP asal, bisa berupa IP tunggal, rentang CIDR, atau nama grup network yang didefinisikan terpisah. Pola klasik: layanan internal cukup one_factor jika diakses dari VPN atau LAN, tapi butuh two_factor jika diakses dari internet.

#Empat Kebijakan: Kapan Memakai yang Mana

bypass: halaman yang memang harus terbuka, seperti halaman publik atau aset statis.
one_factor: layanan yang cukup aman dengan password. Kenyamanan diutamakan.
two_factor: layanan sensitif: admin panel, dashboard infrastruktur, atau data pribadi. Butuh password plus metode kedua.
deny: blokir tegas, biasanya untuk layanan tertentu bagi grup pengguna tertentu.

Ingat logikanya: one_factor hanya menunda serangan selama password kalian belum bocor. two_factor menambahkan lapisan kedua sehingga password yang bocor saja tidak cukup untuk masuk.

#Urutan Evaluasi: First Match Wins

Inilah poin yang paling sering salah dipahami. Authelia mengevaluasi rules dari atas ke bawah, dan aturan pertama yang cocoklah yang menentukan kebijakan — permintaan berhenti dievaluasi di sana. Jika tidak ada aturan yang cocok, barulah default_policy dipakai.

Implikasi praktisnya: taruh aturan yang lebih spesifik di posisi atas, dan aturan umum (catch-all) di bawah. Jika urutan dibalik, aturan umum akan menelan aturan spesifik di belakangnya — persis seperti daftar bouncer di sebuah klub: siapa pun yang lebih dulu lolos pintu pertama tidak akan sempat diperiksa pintu berikutnya.

Aturan spesifik sebelum catch-all

access_control:
  default_policy: deny
  rules:
    - domain: "admin.example.com"
      subject: "group:admins"
      policy: two_factor
    - domain: "*.example.com"
      policy: one_factor

Warning

Jika kalian membalik dua aturan di atas, subdomain admin.example.com akan kalah dengan aturan *.example.com yang terlebih dahulu cocok, sehingga panel admin hanya dilindungi one_factor. Selalu tulis aturan paling spesifik paling atas, lalu uji setiap perubahan.

#Aturan Praktis: Root, API, dan Aset Statis

Saat membangun konfigurasi nyata, ada tiga pola yang hampir selalu muncul. Contoh lengkapnya:

access_control untuk layanan sehari-hari

access_control:
  default_policy: deny
  rules:
    - domain: "example.com"
      resources: ["^/(assets|static|images|favicon\\.ico)/?.*$"]
      policy: bypass
    - domain: "api.example.com"
      policy: one_factor
    - domain: "admin.example.com"
      subject: "group:admins"
      policy: two_factor
    - domain: "*.example.com"
      policy: one_factor

Aset statis di-bypass: CSS, JavaScript, gambar, dan favicon harus bisa dimuat browser sebelum proses autentikasi selesai. Jika aset ini ikut dilindungi, halaman login atau aplikasi bisa tampil rusak. Mem-bypass aset juga mengurangi beban pemeriksaan untuk permintaan yang tidak sensitif.
Root satu faktor: sebagian besar layanan cukup dilindungi password untuk kenyamanan penggunaan sehari-hari.
Panel admin dua faktor: area yang paling sensitif wajib memakai two_factor karena dampak komprominya paling besar.

Caution

Mem-bypass aset statis berarti data di dalam path tersebut bisa diakses siapa pun. Jangan pernah menaruh data sensitif, konfigurasi, atau backup di bawah path yang di-bypass. Aturan bypass yang terlalu lebar adalah salah satu kesalahan konfigurasi paling umum di dunia nyata.

#Penutup

Poin kunci episode ini:

default_policy: deny adalah jaring pengaman yang membuat semua layanan terkunci secara default.
Satu aturan terdiri dari kriteria domain, domain_regex, subject, resources, methods, networks, dan query, plus satu policy.
bypass untuk publik, one_factor untuk layanan umum, two_factor untuk yang sensitif, deny untuk blokir tegas.
Evaluasi aturan bersifat first match wins: aturan spesifik harus diletakkan di atas aturan umum.
Aset statis layak di-bypass, tetapi pastikan tidak ada data sensitif di dalamnya.

Sekarang kalian sudah bisa menentukan siapa boleh masuk ke mana. Namun ada satu pertanyaan lanjutan: setelah login, bagaimana Authelia mengingat siapa kalian di setiap permintaan berikutnya? Jawabannya ada di mekanisme session — topik yang akan kalian bedah di episode 7 tentang session management, dari cookie hingga penyimpanan session di Redis.