Belajar Authentik - SAML Provider Configuration
Mengonfigurasi Authentik sebagai SAML 2.0 Identity Provider: memahami peran IdP dan SP, mengatur ACS URL, Entity ID, NameID policy, dan sertifikat penandatanganan, mengekspor metadata IdP, memetakan atribut lewat property mappings, hingga kapan memilih SAML dibanding OIDC.
#Pendahuluan
Fase proxy provider telah selesai: di episode 12 dan 13 kalian melindungi aplikasi via forward auth. Mulai episode ini kita masuk fase baru yang berbeda sifatnya: SAML. Jika forward auth melindungi aplikasi yang tidak punya sistem login sendiri, SAML menghubungkan Authentik dengan aplikasi enterprise yang memiliki sistem login sendiri dan menuntut standar federasi.
OIDC (yang kita bahas di fase 3) adalah standar autentikasi modern berbasis JSON. SAML 2.0 adalah pendahulunya yang berbasis XML — lebih tua, lebih verbose, tetapi masih menjadi standar wajib di banyak produk enterprise: Google Workspace, AWS, Salesforce, dan Office 365. Di episode ini kalian mengubah Authentik menjadi Identity Provider (IdP) SAML.
#IdP dan SP: Dua Peran yang Berbeda
Dalam SAML, selalu ada dua pihak:
- Identity Provider (IdP) — pihak yang memverifikasi identitas dan menerbitkan assertion. Dalam konteks kita: Authentik.
- Service Provider (SP) — aplikasi yang memakai assertion untuk mengenali user. Contoh: GitLab, Nextcloud, Google Workspace.
Pertukarannya sederhana: user membuka aplikasi (SP), SP melempar pertanyaan ke IdP "siapa user ini?", user login di Authentik, Authentik menerbitkan assertion — dokumen XML berisi identitas user yang ditandatangani — lalu SP memvalidasi signature dan menerima user.
Analogi: SP adalah resepsionis yang meminta kartu identitas bermeterai dari pengunjung. IdP adalah kantor catatan sipil yang menerbitkannya. Resepsionis tidak mengenal pengunjung secara pribadi — ia hanya percaya pada tanda tangan kantor catatan sipil.
#Membuat SAML Provider
Di UI Authentik, navigasikan ke Applications → Applications → New Application, pilih tipe SAML Provider, lalu isi pengaturan berikut:
| Field | Arti |
|---|---|
| Name | Nama provider, misalnya "GitLab SAML" |
| Authorization flow | Alur yang dijalankan saat user login (biasanya default-authentication-flow) |
| ACS URL | Alamat SP yang menerima assertion (Assertion Consumer Service) |
| Audience | Entity ID SP — pengenal unik aplikasi di dunia SAML |
| Issuer | Default-nya URL metadata IdP; bisa di-override di Advanced settings |
| Service Provider Binding | Cara assertion dikirim: HTTP POST atau HTTP Redirect |
| NameID Policy | Format identitas user dalam assertion |
| Signing certificate | Sertifikat yang menandatangani assertion dan respons |
ACS URL dan Audience diambil dari aplikasi yang diintegrasikan — keduanya bukan nilai yang kalian tentukan sendiri. Ini bagian yang paling sering tertukar: kalian tidak menebak nilai, kalian membacanya dari dokumentasi atau metadata SP.
#Binding: POST vs Redirect
Binding menentukan cara assertion diangkut lewat HTTP:
- HTTP POST — assertion dikirim dalam body form POST. Lebih aman untuk data besar seperti XML assertion yang ditandatangani, karena tidak terikat oleh panjang URL.
- HTTP Redirect — assertion dikirim sebagai parameter query URL. Praktis, tetapi dibatasi panjang URL dan kurang cocok untuk assertion besar.
Sebagian besar aplikasi modern mendukung POST; itu juga yang disarankan Authentik. Pilih POST kecuali SP menuntut Redirect.
#Sertifikat Penandatanganan
SAML mengandalkan trust kriptografis. Assertion harus ditandatangani agar SP yakin assertion itu benar berasal dari Authentik dan tidak diubah di tengah jalan.
Langkahnya di Authentik: buat pasangan kunci di Certificates (atau gunakan yang sudah ada), lalu pilih sebagai Signing certificate pada provider. Dua algoritma yang terkait:
- Signing algorithm — metode kriptografi penandatanganan, misalnya
RSA-SHA256. - Digest algorithm — fungsi hash yang dipakai dalam proses signature, misalnya
SHA-256.
Warning
Jika SP gagal memvalidasi signature, periksa dulu kunci di sisi SP. Signature divalidasi dengan public key — bukan private key — yang harus cocok dengan sertifikat yang kalian pilih di Authentik. Ganti sertifikat berarti semua SP yang menunjuk ke Authentik harus diperbarui metadatanya.
#NameID: Identitas User dalam Assertion
NameID adalah pengenal unik user dalam assertion — semacam nomor induk yang stabil, tidak berubah walau atribut lain berganti. Format yang didukung:
persistent— identitas hash user yang stabil. Pilihan terbaik secara default.transient— identitas berbasis sesi, berubah setiap login.emailAddress— memakai email user sebagai NameID. Berisiko jika user bebas mengganti email.windowsDomainQualifiedName— identitas berbasis UPN, relevan untuk lingkungan Active Directory.
Authentik mengizinkan memilih property mapping yang menghasilkan NameID lewat field NameID property mapping. Jika dikosongkan, kebijakan NameID dari permintaan SP yang berlaku.
#Metadata: Jembatan Kepercayaan
SAML tidak menuntut menyalin nilai manual bila kedua pihak menyediakan metadata — dokumen XML yang memuat endpoint, binding, sertifikat, dan pengenal unik.
Metadata IdP Authentik tersedia di:
https://authentik.example.com/application/saml/<application-slug>/metadata/Ganti <application-slug> dengan slug aplikasi SAML yang kalian buat. Potongan metadatanya menyerupai ini:
<EntityDescriptor entityID="https://authentik.example.com/application/saml/gitlab/metadata/">
<SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" ...>
<KeyDescriptor use="signing">
<KeyInfo><X509Data><X509Certificate>...</X509Certificate></X509Data></KeyInfo>
</KeyDescriptor>
...
</SPSSODescriptor>
</EntityDescriptor>Di UI, metadata bisa diunduh lewat tombol Download pada halaman provider, atau diakses lewat tab Metadata. Sebaliknya, jika SP menyediakan metadata XML, Authentik bisa membuat provider secara otomatis dari metadata tersebut — pilih tipe SAML Provider from Metadata saat membuat provider.
#Property Mapping Atribut
Assertion bisa membawa atribut tambahan di luar NameID — email, nama, grup — lewat property mappings. Authentik menyediakan mapping bawaan untuk email, username, name, groups, dan UID. Bila SP menuntut format khusus, buat mapping kustom. Contoh SP yang ingin givenname dan surname terpisah:
return request.user.name.split(" ", 1)[0]return request.user.name.rsplit(" ", 1)[-1]Atur SAML Attribute Name sesuai ekspektasi SP (misalnya http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname), lalu pilih mapping tersebut pada provider.
#Kapan SAML, Kapan OIDC?
| Pertimbangan | SAML | OIDC |
|---|---|---|
| Format | XML, verbose | JSON, ringkas |
| Aplikasi enterprise | Google Workspace, AWS, Salesforce, Office 365 | Aplikasi modern |
| Kemudahan integrasi | Perlu metadata dan sertifikat | Discovery URL sederhana |
| Token | Assertion XML | JWT |
Aturan praktisnya: untuk aplikasi baru dan integrasi modern, pilih OIDC. Untuk aplikasi enterprise yang hanya mendukung SAML, gunakan SAML. Jangan memilih SAML hanya karena "lebih aman" — keduanya aman bila dikonfigurasi benar.
#Penutup
Episode ini mengonfigurasi Authentik sebagai SAML IdP: memahami peran IdP dan SP, mengisi ACS URL, Audience, dan binding POST, menyiapkan sertifikat penandatanganan beserta signing dan digest algorithm, memilih NameID policy yang stabil, mengekspor metadata IdP lewat URL, memetakan atribut dengan property mappings, dan memutuskan kapan SAML dibanding OIDC.
Di episode 15, fondasi ini kalian pakai untuk menghubungkan SP nyata — GitLab, Nextcloud, Google Workspace, dan AWS — melalui pertukaran metadata, lalu menelusuri troubleshooting SAML yang paling sering membuat orang menyerah. Sampai jumpa!