Belajar Authentik - Policies: Conditional Logic

#Pendahuluan

Di episode 5, kalian sudah membangun fondasi identitas: user, grup, dan atribut. Sekarang Authentik sudah bisa menjawab pertanyaan pertama, siapa kamu, lewat alur autentikasi. Tapi ada pertanyaan kedua yang tidak kalah penting: apa yang boleh kamu lakukan setelah masuk?

Jawabannya ada di policy — conditional logic yang menentukan keputusan ya atau tidak di hampir setiap titik penting Authentik. Analoginya begini: authentication seperti penjaga di lobi gedung yang memeriksa kartu identitas, sedangkan policy adalah daftar ruangan yang boleh dimasuki, lengkap dengan jam buka dan aturan khusus per lantai. Di episode ini kalian akan belajar memprogram daftar ruangan itu.

#Apa Itu Policy dan Policy Binding

Secara sederhana, policy adalah keputusan boolean: lulus (pass) atau gagal (fail). Keputusan inilah yang kemudian menggerakkan logika Authentik. Ada lima tempat utama policy bisa di-bind (dilampirkan):

• Flow: menentukan apakah user boleh memulai atau melanjutkan sebuah flow.
• Stage binding: menentukan apakah sebuah stage berjalan di dalam flow.
• Application: menentukan apakah user boleh membuka aplikasi.
• Source: menentukan apakah sebuah source boleh dipakai untuk login atau enrollment.
• Prompt stage: sebagai validation policy untuk data yang baru diketik user.

Selain policy, kalian juga bisa meng-bind user atau grup secara langsung ke target yang sama. Binding langsung ini dievaluasi sebagai pemeriksaan keanggotaan sederhana — berguna saat kalian hanya butuh aturan izinkan atau tolak tanpa membuat objek policy baru.

#Tipe-Tipe Policy di Authentik

Authentik menyediakan beberapa tipe policy bawaan yang bisa dipakai tanpa menulis kode:

• Expression policy: menulis logika bebas dalam Python. Paling fleksibel.
• Event matcher policy: mencocokkan event tertentu, berguna untuk memicu aksi.
• Have application policy: memeriksa apakah user memiliki akses ke sebuah aplikasi.
• Password policy: memvalidasi kekuatan password terhadap aturan kompleksitas.
• Password expiry policy: memeriksa masa berlaku password.
• Password uniqueness policy: memastikan password tidak dipakai ulang.
• Reputation policy: memblokir IP atau user dengan skor reputasi buruk.
• GeoIP policy: membatasi akses berdasarkan lokasi geografis.
• Dummy policy: mengembalikan nilai tetap untuk kebutuhan testing.

Untuk sebagian besar kebutuhan otorisasi, expression policy adalah pilihan utama — justru karena ia bisa menggabungkan semua kondisi di atas dalam satu ekspresi.

#Expression Policy: Otak dari Semua Aturan Kustom

Expression policy adalah potongan kode Python yang dieksekusi di sisi server Authentik saat policy dievaluasi. Ekspresi menerima konteks kaya, lalu mengembalikan True jika lulus atau False jika gagal. Contoh paling umum: menolak akses jika user bukan anggota grup tertentu.

Expression policy: akses hanya untuk grup app-admins

if ak_is_group_member(request.user, name="app-admins"):
    return True
ak_message("Akses ditolak: kamu bukan anggota grup app-admins")
return False

Perhatikan dua hal di atas. Pertama, helper ak_is_group_member(user, name="...") memeriksa keanggotaan grup dengan bersih. Kedua, ak_message("...") mengisi pesan yang akan ditampilkan ke user ketika policy gagal — jangan biarkan user menebak sendiri alasan penolakannya.

#Konteks yang Tersedia dalam Ekspresi

Beberapa variabel dan helper yang paling sering dipakai:

• request.user: user yang sedang dievaluasi terhadap policy ini.
• request.context: dictionary berisi data dinamis dari eksekusi flow.
• ak_is_group_member(user, name="..."): cek keanggotaan grup.
• ak_user_has_authenticator(user): cek apakah user punya perangkat MFA.
• ak_message("..."): set pesan yang terlihat user.
• ak_client_ip: objek IP klien yang sudah di-parse, cocok untuk cek jaringan.
• regex_match(value, pattern) dan regex_replace(value, pattern, repl): manipulasi string.

Satu jebakan klasik: ketika policy berjalan di dalam flow autentikasi, request.user belum tentu user yang sedang login — bisa saja masih AnonymousUser sampai sebuah stage user login menetapkannya. Untuk kasus ini, dokumentasi menyarankan membaca pending_user dari flow context (misalnya request.context.get("pending_user")) agar keputusan memakai identitas yang benar.

#Evaluasi Policy: Urutan, Any, dan All

Policy yang di-bind ke target yang sama dievaluasi berurutan dari atas ke bawah (ascending order). Ini penting saat membaca log maupun saat beberapa policy menghasilkan pesan untuk user.

Selain urutan, setiap target binding memiliki Policy engine mode:

• Any: target lolos jika salah satu binding lulus. Ini default.
• All: target lolos hanya jika semua binding lulus.

Ada juga beberapa pengaturan tambahan yang sering menyelamatkan waktu kalian di produksi:

• Negate: membalik hasil binding, berguna untuk mengekspresikan "semua orang kecuali grup ini".
• Timeout: batas waktu eksekusi policy (default 30 detik), penting untuk policy yang memanggil sistem eksternal.
• Failure result: apakah policy yang error dianggap pass atau fail.
• Execution logging: mencatat setiap eksekusi policy, bukan hanya yang gagal — sangat membantu saat debugging.

#Contoh Penggunaan Umum

#Akses Berbasis Grup

Policy di awal episode ini sudah menunjukkan polanya: tolak jika bukan anggota grup app-admins. Binding ke application berarti aplikasi hanya bisa dibuka anggota grup tersebut.

#Akses Berbasis Waktu

Ingin layanan hanya bisa diakses jam kerja? Cukup bandingkan jam saat evaluasi berlangsung.

Expression policy: hanya jam kerja

from datetime import datetime
now = datetime.now()
return 9 <= now.hour < 17

#Pembatasan Alamat IP

Untuk layanan internal yang seharusnya hanya bisa diakses dari jaringan kantor, gunakan perbandingan jaringan.

Expression policy: hanya dari jaringan internal

from ipaddress import ip_network
return ak_client_ip in ip_network("10.0.0.0/24")

#MFA dan Consent

Ini pola yang paling banyak dipakai: bind sebuah policy ke stage binding, sehingga stage tertentu — misalnya authenticator validate — hanya berjalan untuk sebagian user atau aplikasi. Persis inilah yang akan kalian bedah lebih dalam di episode 7 tentang MFA.

#Testing Policy

Jangan pernah mengandalkan tebakan. Authentik menyediakan alat untuk menguji policy sebelum dipakai:

• Policy tester: jalankan policy terhadap user atau request contoh, lalu lihat hasil lulus atau gagal.
• Execution logging: aktifkan untuk melihat setiap eksekusi beserta konteksnya.
• Event logs: setiap penolakan tercatat di halaman events beserta pesan dari ak_message.
• Flow inspector: untuk policy yang terikat stage, jalankan flow dan periksa di titik mana policy dievaluasi.

#Penutup

Poin kunci episode ini:

• Policy adalah keputusan boolean yang bisa di-bind ke flow, stage binding, application, source, dan prompt stage.
• Expression policy memakai Python dengan konteks request.user dan request.context plus helper seperti ak_is_group_member.
• Evaluasi berurutan dengan mode Any (default) dan All, ditambah opsi negate, timeout, dan failure result.
• Pola umum: akses berbasis grup, jam kerja, alamat IP, dan pemaksaan MFA.
• Selalu uji policy lewat policy tester dan execution logging.

Sekarang kalian sudah bisa memprogram logika "siapa boleh masuk". Tapi masih ada pertanyaan menggoda: bagaimana kalau kondisi itu berbunyi "semua admin wajib MFA"? Di episode 7, kalian akan membedah authentication stages dan mekanisme Multi-Factor Authentication — mulai dari identification, password, sampai authenticator validate — beserta cara binding-nya ke aplikasi.