Belajar SOAP - WS-Security: Konsep & Token

#Pendahuluan

Setelah di episode 13 kita membangun observability, sekarang kita masuk ke salah satu alasan utama SOAP masih hidup: WS-Security (WSS). Kalian mungkin bertanya-tanya — "bukankah HTTPS sudah cukup?" Jawabannya: tidak untuk semua kebutuhan enterprise. Episode ini menjelaskan mengapa.

Mengapa penting? Dalam integrasi keuangan dan kesehatan, dokumen yang lewat tidak boleh hanya sampai — ia harus bisa dibuktikan siapa yang mengirim, kapan, dan bahwa tidak ada yang mengubahnya. TLS melindungi transport; WS-Security melindungi pesan di level yang bisa bertahan di luar koneksi. Pemahaman ini membedakan engineer yang memahami keamanan SOAP dari yang hanya memakai boilerplate.

#Transport Security vs Message Security

Aspek	TLS (HTTPS)	WS-Security (Message)
Melindungi	Saluran koneksi	Isi pesan itu sendiri
Berlaku selama	Koneksi terbuka	Masa hidup pesan (berhari-hari)
Bisa diverifikasi penerima akhir	Tidak (hanya peer langsung)	Ya
Signing/encryption per-elemen	Tidak	Ya
Bukti non-repudiation	Tidak	Ya (dengan sertifikat)

Skenario nyata yang membuat TLS tidak cukup:

Intermediary terpercaya — pesan harus dibaca dan ditandatangani ulang di gateway mitra; TLS berakhir di gateway, tapi keamanan pesan harus sampai penerima akhir.
Audit kepatuhan — regulasi menuntut bukti integritas dan asal-usul pesan yang bisa disimpan bertahun-tahun, bukan hanya selama koneksi.
Routing tanpa baca — header bisa diproses oleh pihak yang tidak berhak melihat isi body.

Aturan yang benar: TLS melindungi saluran, WS-Security melindungi pesan — keduanya dipakai bersama, bukan salah satu.

#Anatomi Header Security

WS-Security (OASIS SOAP Message Security 1.1) menyimpan semua artefak keamanan di satu elemen Security di dalam header SOAP:

Header Security dengan UsernameToken

<soap:Header
  xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  <wsse:Security>
    <wsse:Timestamp wsu:Id="TS-1">
      <wsu:Created>2026-08-16T02:30:00Z</wsu:Created>
      <wsu:Expires>2026-08-16T02:35:00Z</wsu:Expires>
    </wsse:Timestamp>
    <wsse:UsernameToken wsu:Id="UT-1">
      <wsse:Username>integrasi-mitra</wsse:Username>
      <wsse:Password Type=
        "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">
        qX9b... </wsse:Password>
      <wsse:Nonce EncodingType=".../Base64">K2V0Mzk=</wsse:Nonce>
      <wsse:Created>2026-08-16T02:30:00Z</wsse:Created>
    </wsse:UsernameToken>
  </wsse:Security>
</soap:Header>

Komponen utama:

Elemen	Fungsi	Menangkal
`Timestamp`	Waktu pembuatan/kedaluwarsa pesan	Replay attack
`UsernameToken`	Autentikasi user/mitra (password digest)	Sniffing password
`BinarySecurityToken`	Pembawa sertifikat X.509	—
`Signature`	Tanda tangan digital atas elemen	Tampering
`EncryptedData`	Enkripsi elemen tertentu	Sniffing isi pesan

#Token-Token Utama

#UsernameToken

Token paling sederhana dan banyak dipakai untuk integrasi mitra. Jangan pernah kirim password plaintext — gunakan PasswordDigest: hash SHA-1(nonce + created + password). Karena nonce dan timestamp unik per pesan, digest ini tidak bisa diputar ulang (replay) — bedanya dengan Basic Auth.

Kelebihan: sederhana, didukung semua stack, cocok untuk identitas mitra aplikasi.
Kekurangan: autentikasi saja — tidak membuktikan integritas/kerahasiaan pesan.

#X.509 BinarySecurityToken

Sertifikat X.509 dikirim sebagai token untuk mendukung signing dan encryption:

BinarySecurityToken

<wsse:BinarySecurityToken
  EncodingType="...#Base64Binary"
  ValueType="...#X509v3"
  wsu:Id="X509-1">
  MIICXzCCAcSgAwIBAgIFAJ9m... 
</wsse:BinarySecurityToken>

Sertifikat ini dipakai sebagai kunci untuk menandatangani dan/atau mengenkripsi. Di produksi, sertifikat dikelola oleh PKI (public key infrastructure) — diterbitkan CA, dirotasi berkala, dicabut saat kompromi (episode 16 membahas alurnya).

#Signing dan Encryption

#XML Signature (Integritas + Autentikasi)

Signing menghasilkan Signature di header yang merujuk elemen tertentu (biasanya timestamp + body):

Membuktikan siapa pengirim (kunci privat signer).
Membuktikan tidak ada yang mengubah pesan sejak ditandatangani.
Diverifikasi oleh siapa pun yang punya sertifikat publik signer.

#XML Encryption (Kerahasiaan)

Encryption menyandikan elemen tertentu — biasanya isi body atau field sensitif:

Hanya pemegang kunci yang bisa membuka (biasanya kunci publik penerima).
Bisa dienkripsi sebagian — misal hanya elemen balance dan dokumen, sementara header routing tetap terbaca.

Tip

Kombinasi standar produksi: sign dulu, lalu encrypt (signature dihitung atas plaintext, lalu dienkripsi). Ini memungkinkan penerima memverifikasi signature tanpa bocor isi ke intermediary, dan melindungi dari serangan signature stripping.

#Timestamp: Benteng Anti-Replay

Timestamp adalah pertahanan pertama terhadap replay attack — mengirim ulang pesan yang sama untuk memproses transaksi dua kali. Aturan penerima:

Tolak pesan dengan Created yang lebih tua dari kebijakan (mis. 5 menit).
Tolak pesan dengan Expires yang sudah lewat.
Simpan hash pesan (atau MessageID) yang sudah diproses untuk jangka waktu tertentu.

Timestamps juga wajib disertakan dalam signature — jika tidak, penyerang bisa mengubah timestamp pesan untuk memperpanjang masa berlakunya.

Warning

WS-Security yang salah dikonfigurasi lebih berbahaya daripada tidak ada: signature yang hanya melindungi header tapi bukan body memberi rasa aman palsu. Selalu tentukan elemen mana yang di-sign/encrypt secara eksplisit (biasanya Timestamp + Body), dan verifikasi di sisi penerima bahwa elemen itu benar-benar dilindungi.

#Penutup

Inti yang harus dibawa pulang:

TLS melindungi saluran; WS-Security melindungi pesan — keduanya dipakai bersama.
Header Security membawa Timestamp, UsernameToken, BinarySecurityToken, Signature, dan EncryptedData.
UsernameToken memakai PasswordDigest (nonce + created + password), bukan plaintext.
XML Signature untuk integritas/autentikasi; XML Encryption untuk kerahasiaan; sign dulu lalu encrypt.
Timestamp menangkal replay; sertakan dalam signature.

Di episode 15 selanjutnya kita akan membahas WS-SecurityPolicy & pemrograman dengan WSS4J — menyusun policy keamanan yang terikat ke WSDL dan mengimplementasikan signing, encryption, dan UsernameToken dengan Apache WSS4J 4.0.1 serta interceptor CXF. Sampai jumpa di episode 15!