Belajar SOAP - Authentication & Authorization

#Pendahuluan

Setelah di episode 15 kita membangun WS-Security dengan WSS4J, sekarang kita jawab pertanyaan krusial: siapa yang boleh memanggil, dan apa yang boleh ia lakukan? Ini adalah authentication (membuktikan identitas) dan authorization (menentukan hak akses) — dua hal yang sering disalahartikan sebagai satu.

Mengapa penting? Di integrasi B2B, setiap mitra punya hak yang berbeda: mitra pengecekan saldo tidak boleh bisa transfer, mitra internal boleh melihat data sensitif. Kebocoran di layer ini bukan sekadar bug — ia adalah pintu masuk insiden keamanan. Episode ini membekali kalian memilih mekanisme yang tepat dan menerapkan kontrol akses dengan benar.

#Authentication vs Authorization

Contoh nyata: UsernameToken membuktikan "saya mitra bank B" (authentication); kebijakan RBAC menentukan "mitra bank B boleh getBalance tapi tidak transfer" (authorization). Jangan pernah mencampurnya.

#Opsi Autentikasi untuk SOAP

#HTTP Basic / Digest

• Basic: Authorization: Basic base64(user:pass) di header HTTP. Sederhana, tetapi password hampir plaintext (hanya base64) — hanya aman di atas HTTPS.
• Digest: hash berbasis challenge; lebih baik dari Basic, tetapi jarang dipakai untuk SOAP modern.
• Cocok untuk: integrasi internal sederhana di atas HTTPS. Tidak ada integrasi dengan WS-Security, dan tidak menangkal replay tanpa HTTPS yang solid.

#UsernameToken (WS-Security)

Dari episode 14-15: token di header Security, password digest berbasis nonce + timestamp.

• Kelebihan: terintegrasi dengan WS-Security; menangkal replay dengan nonce/timestamp; bisa di-sign.
• Kekurangan: autentikasi identitas aplikasi/mitra — bukan identitas pengguna manusia.
• Cocok untuk: sebagian besar integrasi mitra B2B. Ini opsi default yang direkomendasikan.

#Mutual TLS (mTLS)

Client dan server saling memverifikasi sertifikat di lapisan transport:

• Kelebihan: identitas kriptografis yang kuat, tanpa password; sulit dipalsukan.
• Kekurangan: pengelolaan sertifikat per-mitra berat (penerbitan, distribusi, rotasi, pencabutan).
• Cocok untuk: mitra terbatas dengan kepentingan keamanan tinggi (inter-bank), atau lapisan tambahan di atas UsernameToken.

#SSO: SAML dan WS-Trust

Untuk autentikasi pengguna manusia lintas organisasi, SOAP memakai SAML dan WS-Trust:

• SAML Assertion — pernyataan identitas dari Identity Provider (IdP) yang dikirim di header Security sebagai token.
• WS-Trust — protokol untuk minta dan memperbarui token keamanan lewat operasi RequestSecurityToken (RST) ke STS (Security Token Service).

<wsse:Security xmlns:wsse="...secext-1.0.xsd">
  <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="saml-8821" IssueInstant="2026-08-16T02:30:00Z"
    Version="2.0">
    <saml:Subject>
      <saml:NameID>user@mitra-bank.co.id</saml:NameID>
    </saml:Subject>
    <saml:Conditions NotBefore="2026-08-16T02:25:00Z"
      NotOnOrAfter="2026-08-16T04:25:00Z"/>
  </saml:Assertion>
</wsse:Security>

• Cocok untuk: enterprise SSO, portal web, dan integrasi lintas organisasi yang menuntut federasi identitas.

#Authorization: RBAC di Level Operasi

Setelah identitas terbukti, tentukan hak per operasi. Implementasi RBAC paling sederhana adalah peta (peran → daftar operasi):

RBAC sederhana

public class AccessControl {
    private static final Map<String, Set<String>> ROLE_OPS =
        Map.of(
            "mitra-bank-b", Set.of("getBalance", "getExchangeRate"),
            "mitra-bank-c", Set.of("getBalance", "transfer"),
            "internal", Set.of("getBalance", "transfer", "audit")
        );
 
    public static void check(String role, String operation) {
        if (!ROLE_OPS.getOrDefault(role, Set.of()).contains(operation)) {
            throw new SecurityException("Hak akses ditolak untuk " + operation);
        }
    }
}

Panggil di awal setiap operasi service:

Authorization di service

@WebMethod
public BigDecimal getBalance(String accountNo) {
    String role = resolveRoleFromSecurityHeader();
    AccessControl.check(role, "getBalance");
    // ... logika bisnis
}

#Menjaga Kerahasiaan Credentials

#Jangan Hardcode

Password, kunci keystore, dan secret lain tidak pernah boleh di-hardcode di kode atau commit ke repository. Pola yang benar:

Ambil secret dari environment

pc.setPassword(System.getenv("MITRA_PASSWORD"));

#Vault untuk Produksi

Di produksi, gunakan tool manajemen secret (Vault, OpenBao, atau secret manager cloud) agar secret bisa dirotasi tanpa redeploy:

App start
  -> Vault login (menggunakan identitas app / token)
  -> Baca MITRA_PASSWORD dan kunci keystore
  -> Injeksi ke memori proses (bukan disk)
  -> Aplikasi berjalan dengan secret di memori

Rotasi jadi aman: ganti nilai di Vault, aplikasi mengambil versi baru tanpa restart. Detail lengkapnya ada di series learn-secret-management-vault — di sini prinsipnya: secret keluar dari kode, hidup di tempat terkontrol.

#Prinsip Least Privilege

• Setiap mitra mendapat credential terpisah — jangan berbagi satu user untuk semua mitra (audit jadi mustahil dan pencabutan akses satu mitra mengganggu yang lain).
• Hak yang diberikan seminimal mungkin untuk kebutuhan operasional mitra.
• Cabut akses saat kontrak mitra berakhir — ada proses offboarding, bukan hanya "diamkan".

#Penutup

Inti yang harus dibawa pulang:

• Authentication membuktikan identitas; authorization menentukan hak — dua hal terpisah.
• Pilihan mekanisme: HTTP Basic (HTTPS saja), UsernameToken digest (default B2B), mTLS (keamanan tinggi), SAML/WS-Trust (SSO pengguna manusia).
• Terapkan RBAC di level operasi, di dalam service, bukan hanya di gateway.
• Credentials diambil dari environment/vault, tidak pernah hardcode; rotasi tanpa redeploy.
• Least privilege: credential terpisah per mitra, hak seminimal mungkin, dan offboarding yang jelas.

Di episode 17 selanjutnya kita akan membahas secure coding & API security testing — serangan XXE, XML Signature Wrapping, schema bypass, dan replay, lalu pengujian dengan SoapUI Security, Burp/ZAP untuk SOAP/XML, serta checklist pengamanan produksi. Sampai jumpa di episode 17!