Belajar Keycloak - SAML 2.0 Fundamentals | Belajar SSO dengan Keycloak

#Pendahuluan

Di episode 11 kalian menangani siklus hidup session: kapan SSO session dibuat, bagaimana idle timeout dan max timeout membatasinya, serta bagaimana single logout menarik semua session sekaligus. Episode 12 ini membuka fase baru dengan SAML 2.0, protokol autentikasi berbasis XML yang menjadi standar de facto di lingkungan enterprise. Kalian mungkin bertanya, mengapa belajar protokol yang terkesan tua di era OIDC? Karena puluhan ribu aplikasi korporat — mulai dari portal HR, ERP, hingga aplikasi supply chain — hanya menyediakan integrasi SAML. Episode ini menanamkan fondasinya agar integrasi di episode 13 dan 14 terasa ringan.

#Mengapa SAML 2.0 Masih Menjadi Standar Enterprise

SAML (Security Assertion Markup Language) 2.0 distandardisasi oleh OASIS pada tahun 2005 dan tetap menjadi protokol pilihan untuk federation di dunia korporat. Tiga ciri yang membuatnya bertahan:

Berbasis XML — seluruh pesan (request, response, assertion) direpresentasikan sebagai dokumen XML yang ketat, bisa divalidasi dengan skema XSD dan ditandatangani dengan XML Signature.
Standar enterprise — dukungannya ada di hampir semua produk identitas: Active Directory Federation Services, Okta, OneLogin, dan tentu saja Keycloak.
Federation use cases — dirancang untuk menghubungkan identitas lintas organisasi lewat trust antara IdP dan SP, tanpa pernah berbagi kredensial.

urn:oasis:names:tc:SAML:2.0:assertion adalah namespace resmi untuk elemen assertion. Kalian akan sering melihat string seperti ini di metadata dan dokumen request — penanda bahwa dokumen tersebut mengikuti SAML 2.0, bukan versi sebelumnya.

#SAML 2.0 vs OIDC

Sebelum mendalami komponen, penting melihat peta perbandingannya dengan OIDC yang sudah kalian kuasai:

Aspek	SAML 2.0	OpenID Connect
Format pesan	XML (assertion, response)	JSON (JWT)
Transport utama	HTTP Redirect dan HTTP POST	HTTP Redirect dan JSON
Discovery	Metadata XML (entity descriptor)	OpenID Configuration dan JWKS
Identitas user	NameID dalam assertion	Claim `sub` dalam ID token
Logout	SLO via redirect atau SOAP	RP-initiated dan back-channel logout
Kecocokan	Aplikasi enterprise dan legacy	Aplikasi modern, SPA, mobile

Aturan praktis dari episode 2 berlaku: pilih OIDC untuk aplikasi baru yang kalian bangun sendiri, pilih SAML ketika aplikasi yang diintegrasikan — biasanya produk vendor — hanya mendukung SAML.

#Komponen Inti SAML

SAML bekerja dengan dua peran utama dan sejumlah elemen penghubung:

Identity Provider (IdP) — entitas yang memegang identitas dan menerbitkan assertion. Dalam series ini, IdP-nya adalah Keycloak.
Service Provider (SP) — aplikasi yang melindungi resource-nya dengan menerima assertion dari IdP.
Assertion — pernyataan yang dikeluarkan IdP tentang user, dijadikan bukti autentikasi oleh SP.
Binding — cara pesan SAML ditransportasikan antar pihak.
Profile — kombinasi assertion, protokol, dan binding yang membentuk skenario tertentu, misalnya Web Browser SSO Profile.

#Binding yang Paling Sering Dipakai

Binding	Mekanisme	Kelebihan	Kekurangan
HTTP Redirect	Pesan dikirim sebagai parameter query GET	Ringan, cocok untuk AuthnRequest	Terbatas panjang URL
HTTP POST	Pesan ditempel di form HTML yang auto-submit	Bisa membawa dokumen besar	Sedikit lebih berat
SOAP	Pertukaran langsung antar server tanpa browser	Cocok untuk back-channel, misal SLO	Tidak jalan bila ada NAT

Kebanyakan implementasi modern memakai kombinasi: AuthnRequest lewat HTTP Redirect, Response lewat HTTP POST.

#Dua Alur yang Wajib Kalian Pahami

#Alur SP-Initiated

Alur yang paling umum: user memulai dari aplikasi. Berikut langkahnya:

Langkah alur SP-initiated

1. User membuka aplikasi (SP) dan menekan tombol login
2. SP menyusun AuthnRequest dan mengirim ke IdP via HTTP Redirect
3. IdP mengecek sesi, meminta kredensial bila belum login
4. IdP menyusun Response berisi Assertion dan menandatanganinya
5. Browser mengirim Response ke endpoint ACS milik SP via HTTP POST
6. SP memvalidasi signature dan membangun session lokal

Di langkah 2, SP mengisi parameter SAMLRequest pada query string. Saat IdP menjawab, ia menambahkan parameter RelayState untuk membawa state kembali — pastikan kalian mengembalikannya apa adanya.

#Alur IdP-Initiated

Kebalikan dari alur di atas: user membuka portal IdP terlebih dahulu, memilih aplikasi tujuan, lalu IdP mengirimkan assertion tanpa ada AuthnRequest dari SP. Lebih cepat untuk user, tetapi kurang aman karena SP tidak pernah memverifikasi asal permintaan — assertion bisa di-paksa tanpa inisiatif SP.

#Assertion Creation dan Validation

Pembuatan assertion terjadi di IdP setelah user terbukti; validasinya terjadi di SP: memeriksa signature, masa berlaku, audience, dan status response. Jika salah satu gagal, assertion ditolak.

Tip

Ingat kata kunci: SP-initiated dimulai dari aplikasi, IdP-initiated dimulai dari penyedia identitas. Saat debugging, identifikasi dulu siapa yang memulai alur — kebanyakan kebingungan awal berakar dari sini.

#Struktur Assertion

Assertion adalah inti dari SAML. Ada tiga jenis pernyataan yang bisa dibawanya:

Authentication assertion — bukti bahwa user diautentikasi, termasuk waktu dan metode autentikasi.
Attribute assertion — atribut user seperti email, nama, dan departemen.
Authorization decision statement — keputusan apakah sebuah subject diizinkan melakukan aksi tertentu pada sebuah resource.

Contoh Response yang disederhanakan:

Struktur sederhana SAML Response

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
  <saml:Issuer>https://keycloak.example.com/realms/demo</saml:Issuer>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <saml:Assertion>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">budi@example.com</saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>
    </saml:Subject>
    <saml:AttributeStatement>
      <saml:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml:AttributeValue>budi@example.com</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

Beberapa elemen yang perlu kalian kenali:

Issuer — identitas pembuat assertion; SP biasanya menolak assertion dari issuer yang tidak terdaftar.
NameID — identitas user di mata SP; formatnya (email, persistent, transient) harus cocok dengan kesepakatan.
SubjectConfirmation — mekanisme pengikatan assertion ke recipient; bearer adalah yang paling umum untuk browser flow.
AttributeStatement — wadah atribut yang menjadi bahan mapping di sisi aplikasi.

#Penutup

Pada episode 12 ini, kalian mengenal SAML 2.0 sebagai protokol XML untuk enterprise SSO: perbedaan fundamentalnya dengan OIDC, komponen IdP, SP, assertion, dan binding; alur SP-initiated dan IdP-initiated; serta cara membaca struktur assertion dari issuer sampai attribute statement.

Inti yang harus dibawa pulang:

SAML 2.0 adalah protokol autentikasi berbasis XML yang dirancang untuk federation enterprise, bukan pengganti OAuth 2.0.
Binding menentukan transport — HTTP Redirect untuk request, HTTP POST untuk response besar, SOAP untuk back-channel.
SP-initiated dimulai dari aplikasi, IdP-initiated dimulai dari penyedia identitas, dengan trade-off keamanan yang berbeda.
Assertion adalah bukti autentikasi — signature, masa berlaku, dan audience adalah tiga hal yang divalidasi SP.

Di episode 13 berikutnya, kalian menempatkan Keycloak pada peran IdP SAML: membuat SAML client, mengekspor metadata, mengatur kunci signing dan enkripsi, memilih format NameID, sampai menyiapkan endpoint ACS dan SLS.