Apereo CAS (sebelumnya Jasig CAS) banyak dipakai untuk SSO. Cara pemasangannya agak ribet dan sulit. Kebetulan, versi CAS 5.1.2 sekarang sudah menggunakan Spring Boot sebagai dasarnya.
Keuntungan penggunaan Spring Boot adalah Jasig CAS menggunakan banyak keunggulan framework Spring. Misalnya, teknologi Spring Cloud untuk teknologi devops, Spring Web Flow untuk arsitektur layanan mikro (micro service), service discovery, dan konfigurasi melalui YAML. Sehingga, kita bisa memasang infrastruktur SSO melalui CAS tanpa harus mengoding seperti dahulu. Atau, kita bisa mengembangkan layanan yang terpisah dari SSO ala layanan mikro.
Sebelum infrastruktur bertambah rumit, saya ingin memberikan jembatan keledai. Sebab, saya pikir SSO ini agak sulit pada awalnya kalau tidak tahu caranya. Saya harap ketika selesai membaca artikel ini, pembaca ada gambaran bagaimana SSO bisa dikembangkan.
Arsitektur yang dipilih
Arsitektur SSO dasar.
Ada banyak pilihan, tetapi saya memilih kapabilitas komponen yang bisa diskalakan secara horizontal dan modern. Misalnya, ada banyak pilihan untuk ruang penyimpan tiket (Ticket Storage), tetapi saya memilih Redis karena dia implementasi modern yang banyak dipakai untuk teknologi dewasa ini.
Setiap komponen yang saya pilih ini dapat dikluster. Saya memilih untuk mengembangkan satu layanan per mesin. Nanti kalau sudah mengerti teknologi perawanan, [uhuk colek Utian Ayuba] Anda bisa mengubah setiap ini menjadi konfigurasi devops macam Ansible, Puppet, Chef, Vagrant, atau apa pun agama Anda.
CAS IdP
CAS IdP adalah mesin utama yang menyediakan profil, otentikasi, dan otorisasi. Semua klien terhubung ke sana.
Cara buat:
CAS Ticket Storage
Secara baku CAS IdP menyimpan tiket sesi pada memori. Namun, untuk arsitektur kluster dan skalabilitas, lebih baik menggunakan Redis. Mengapa Redis? Karena Redis utamanya menggunakan memori.
Untuk peladen Redis tidak perlu dikluster. Lebih baik satu instans Redis yang memakan memori 24 GB dari pada membuat kluster.
Cara buat:
CAS Service Storage
Satu situs/sistem/aplikasi yang menggunakan CAS untuk SSO disebut satu layanan (service). Setiap layanan dapat didefinisikan logo, URL, ACL pengguna, dan sebagainya secara granular. Itu semua secara baku disimpan oleh CAS IdP di berkas JSON.
Untuk pengelolaan yang lebih baik, saya memilih PostgreSQL sebagai ruang penyimpan. Pengalaman saya membandingkan PostgreSQL dengan MySQL mengatakan bahwa PostgreSQL rajanya basisdata untuk basisdata perangkat lunak bebas terbuka. Waktu itu saya membandingkan layanan Roundcube Webmail dengan MySQL dan PostgreSQL. Anda sebagai pengguna Webmail UI pasti merasakan bagaimana Webmail UI itu seperti mengakses sistem HTML statik.
Saya, sih, tidak apa kalau ada yang mau menggunakan MongoDB atau yang lainnya. Tetapi saya memilih karena daftar layanan ini tidak perlu kecepatan khusus. Selain itu, daftar layanan butuh untuk tahan banting, saya lebih memilih PostgreSQL. Tentu saja, saya takkan memilih Redis.
Cara buat:
CAS Authentication Provider
Normalnya CAS menggunakan Spring Security dengan login casuser dan sandi Mellon. Tentunya, ini buat yang main-main. Untuk yang lebih serius, gunakan LDAP, basis data, atau bahkan layanan REST.
Penyedia otentikasi CAS dapat lebih dari satu (komposit). Tetapi, untuk kali ini, gunakan saja LDAP.
Cara buat:
CAS Service Management Webapp
Aduh, lupa menulis dokumentasi. Silakan simpan URL ini, nanti saya coba tulis. Untuk sementara, langsung saja buat di basisdata. He… he… he….
Studi Kasus: WordPress
Penasaran dengan hasilnya? Langsung saja, buat aplikasi WordPress. Mengapa WordPress? Karena gampang memasangnya. Tinggal pakai plugin WP Cassify, daftarkan URL WP sebagai satu layanan, dan beres!
Cara buat:
TODO:
- Personalisasi halaman login.
- Membuat CAS IdP terkluster (lebih dari satu instans)
- Entahlah….