Pendahuluan: Pentingnya Ketersediaan Sistem (Uptime) 

Setiap proses single sign-on (SSO) dalam lingkungan federasi sepenuhnya bergantung pada Identity Provider (IdP). Ketika organisasi Anda menggunakan Shibboleth sebagai IdP utama, sistem ini menjadi pintu masuk ke puluhan bahkan ratusan aplikasi penting, baik berbasis cloud maupun on-premise. Jika server Shibboleth mengalami gangguan, maka seluruh akses akan terhenti.

Dampak Downtime pada Sistem Identitas 

Bagi perusahaan, bahkan gangguan singkat pada IdP bisa berdampak besar. Hal ini langsung mengganggu layanan penting, mulai dari staf yang mengakses sistem keuangan hingga mahasiswa yang menggunakan platform pembelajaran. Dampaknya meliputi:

• Dampak Finansial: Penurunan produktivitas dan potensi pelanggaran kepatuhan
• Kerusakan Reputasi: Gangguan layanan menurunkan kepercayaan pengguna terhadap sistem IT
• Operasional Terhenti: Aktivitas organisasi bisa berhenti sampai sistem SSO kembali normal

Tujuan dari penerapan arsitektur High Availability (HA) pada Shibboleth adalah memastikan tidak ada downtime, bahkan saat terjadi gangguan seperti kerusakan hardware, error software, atau saat maintenance.

Tantangan Utama HA pada Shibboleth: Manajemen State

Berbeda dengan banyak aplikasi web yang tidak menyimpan state (stateless), Shibboleth IdP adalah aplikasi yang menyimpan state. Artinya, sistem perlu menyimpan informasi penting antar permintaan agar bisa bekerja dengan benar. Inilah tantangan terbesar dalam membangun HA.

Masalah Session State

Saat pengguna berhasil login, sistem membuat session yang menyimpan status login agar tidak perlu login ulang (SSO).

• Perilaku Default: Session disimpan di memori server Shibboleth yang menangani login
• Masalah Utama: Jika server tersebut down, session hilang dan pengguna harus login ulang

Meskipun menggunakan load balancer, perpindahan ke server lain tidak akan mulus jika session tidak tersedia. Agar HA benar-benar tercapai, session harus disimpan di luar server (externalised). Dengan begitu, jika satu server gagal, server lain bisa langsung mengambil session pengguna dari penyimpanan bersama.

Konsistensi Konfigurasi

Selain session, semua node dalam cluster IdP harus memiliki konfigurasi yang sama, seperti:

• Kunci SAML (private key dan sertifikat harus identik)
• File konfigurasi seperti idp.properties dan metadata

Konsistensi ini penting agar semua transaksi tetap dipercaya oleh Service Provider (SP).

Komponen Penting untuk IdP yang Tahan Gangguan

Membangun sistem Shibboleth yang benar-benar HA tidak cukup hanya dengan dua server. Dibutuhkan pendekatan berlapis untuk menghilangkan semua titik kegagalan (single point of failure).

Berikut komponen utamanya:

1. External Load Balancer (L4/L7) 

Ini adalah pintu utama ke sistem IdP.

• Fungsi: Membagi trafik pengguna ke beberapa server IdP secara merata
• Health Check: Harus menggunakan pengecekan level aplikasi (L7), bukan sekadar cek port
  • Misalnya memanggil endpoint /idp/profile/status
  • Jika server tidak sehat, langsung dikeluarkan dari rotasi
• Kebutuhan: Load balancer juga harus HA (biasanya active/passive atau active/active)

2. Cluster Server Aplikasi IdP

Redundansi dimulai dari layer aplikasi.

• Gunakan minimal dua server (VM atau container) dengan konfigurasi yang sama
• Semua node harus memiliki entityID yang sama agar terlihat sebagai satu layanan
• Konfigurasi harus identik di semua server
• Disarankan menggunakan tools seperti Ansible, Puppet, atau Chef agar tetap konsisten

3. Penyimpanan Session Eksternal (Kunci Utama HA)

Tantangan terbesar adalah menyimpan session pengguna. Agar sistem bisa berjalan dalam mode Active/Active (semua server aktif bersamaan), session tidak boleh disimpan di masing-masing server.

Sebaliknya, session harus disimpan di sistem eksternal yang bisa diakses semua node, sehingga jika satu server gagal, server lain bisa langsung melanjutkan tanpa gangguan.

Hal ini dapat dicapai dengan menggunakan sistem penyimpanan eksternal yang juga memiliki high availability:

• Distributed Cache: Sistem cache terdistribusi seperti Redis atau Memcached biasanya menjadi pilihan utama karena sangat cepat. Ini penting agar proses pengecekan session tetap cepat di setiap transaksi SAML.
• Database Khusus: Database yang terklaster (seperti PostgreSQL atau MySQL) juga bisa digunakan, meskipun biasanya sedikit lebih lambat dibanding cache. Untuk data tertentu seperti ID permanen, database tetap menjadi solusi standar.

Dengan menyimpan session di luar server, kita tidak lagi membutuhkan “sticky session” pada load balancer. Ini membuat sistem lebih fleksibel dan benar-benar mendukung pembagian beban secara merata.

4. Backend Service yang High Availability

IdP juga bergantung pada layanan internal lainnya. Agar sistem tetap berjalan tanpa gangguan, layanan ini juga harus memiliki redundansi:

• User Directory (LDAP/AD): Harus terhubung ke beberapa server LDAP atau Active Directory. Jika satu gagal, otomatis berpindah ke server lain.
• Sistem Autentikasi: Sistem seperti MFA atau Kerberos juga harus tersedia di semua node dan memiliki backup

Dengan redundansi di semua layer (network, aplikasi, dan storage), Shibboleth bisa berubah dari titik lemah menjadi fondasi identitas yang kuat dan scalable.

Model Deployment untuk Uptime Maksimal

Untuk mencapai high availability, ada beberapa model yang bisa digunakan, tergantung kebutuhan dan budget:

1. Active/Passive Cluster (Simple Failover) 

Model ini paling sederhana.

• Satu server aktif menangani semua trafik
• Server kedua standby (siap digunakan tapi tidak aktif)

Cara Kerja:
Jika server utama gagal, load balancer langsung mengalihkan trafik ke server cadangan.

Kelebihan:

• Lebih mudah dikelola
• Konfigurasi lebih sederhana

Kekurangan:

• Resource tidak efisien (server cadangan jarang digunakan)
• Ada jeda saat perpindahan (failover), bisa menyebabkan gangguan singkat

2. Active/Active Cluster (Enterprise Standard) 

Semua server aktif bersamaan dan melayani trafik.

Syarat utama:
Session harus disimpan di sistem eksternal agar semua server bisa mengaksesnya.

Kelebihan:

• Semua server digunakan secara optimal
• Mudah ditingkatkan kapasitasnya (tinggal tambah node)
• Jika satu server gagal, sistem tetap berjalan tanpa gangguan

Kekurangan:

• Lebih kompleks
• Butuh konfigurasi dan manajemen yang lebih matang

3. Geo-Redundancy for Disaster Recovery (DR) 

Digunakan untuk menghadapi bencana besar seperti data center down.

Konsep:
Menjalankan beberapa cluster Active/Active di lokasi berbeda.

Cara Kerja:

• Trafik diarahkan ke lokasi terdekat melalui DNS atau Global Load Balancer
• Jika satu lokasi gagal, trafik dialihkan ke lokasi lain

Tantangan:

• Sinkronisasi data antar lokasi
• Biasanya menggunakan replikasi asynchronous agar tetap cepat

Ini adalah tingkat perlindungan tertinggi untuk menjaga layanan tetap berjalan.

Operasional dan Maintenance dalam Lingkungan HA

Membangun sistem HA saja tidak cukup. Untuk menjaga keandalannya, diperlukan proses operasional dan maintenance yang baik dan konsisten.

Monitoring dan Alerting

• 
  
  • Logging Terpusat:
    Setiap node IdP menghasilkan banyak log (akses, audit, error). Mengumpulkan semua log ini ke dalam satu sistem terpusat (seperti Splunk, Elastic Stack, atau log aggregator lainnya) sangat penting untuk troubleshooting. Dengan ini, Anda bisa melacak aktivitas pengguna di berbagai node dalam satu tampilan.
  • Monitoring Kesehatan Aplikasi:
    Monitoring tidak cukup hanya melihat CPU atau memori. Sistem juga harus memantau kesehatan aplikasi Shibboleth itu sendiri, seperti metrik JVM (Java Virtual Machine) dan endpoint status khusus.

Strategi Rolling Deployment

Salah satu keuntungan utama dari cluster Active/Active adalah bisa melakukan maintenance tanpa downtime.

Langkah-langkahnya:

1. Persiapan: Keluarkan satu node (Node A) dari load balancer. Node ini tetap menyelesaikan proses yang sedang berjalan, tapi tidak menerima trafik baru.
2. Upgrade: Lakukan update atau patch pada Node A.
3. Verifikasi: Uji Node A dengan satu transaksi untuk memastikan semuanya berjalan normal.
4. Rotasi: Masukkan kembali Node A ke load balancer, lalu keluarkan Node B.
5. Selesai: Ulangi proses ini untuk semua node lainnya.

Dengan cara ini, maintenance bisa dilakukan tanpa menghentikan layanan, dan patch keamanan bisa diterapkan lebih cepat.

Kesimpulan Utama: Fondasi Kepercayaan dalam Identitas Terfederasi

Menerapkan arsitektur high availability untuk Shibboleth IdP bukan lagi pilihan tambahan, tetapi kebutuhan utama untuk menjaga keandalan dan kepercayaan dalam sistem federasi.

Dengan meninggalkan sistem satu server, Anda mengubah layanan yang sebelumnya rentan menjadi sistem cluster yang kuat dan scalable. Investasi pada komponen seperti load balancer yang andal dan penyimpanan state terpusat akan memberikan manfaat besar dengan memastikan layanan selalu tersedia.

Model Active/Active yang didukung dengan rolling deployment memungkinkan organisasi melakukan maintenance tanpa mengganggu pengguna atau menghentikan aplikasi penting. Ini tidak hanya meningkatkan produktivitas, tetapi juga memperkuat posisi Anda sebagai pengelola identitas yang aman dan terpercaya.