Tag Archives

3 Articles
Konfigurasi CAS 5.1.2
Arsitektur SSO dasar.

Konfigurasi CAS 5.1.2

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

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 IdP Server

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:

Redis Ticket Storage

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 Service Registry

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 Auth LDAP

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:

WordPress Cassify

TODO:

  • Personalisasi halaman login.
  • Membuat CAS IdP terkluster (lebih dari satu instans)
  • Entahlah….
Memasang Enterprise Single Sign-On – CAS  (Sebelumnya Jasig CAS)

Memasang Enterprise Single Sign-On – CAS (Sebelumnya Jasig CAS)

SSO merupakan sebuah konsep yang sebenarnya digunakan di portal korporasi. Namun, pada perkembangannya, justru organisasi pendidikan tinggi mengadopsinya juga untuk login yang terfederasi. Contoh pengguna SSO yang terfederasi untuk perguruan tinggi adalah eduroam.

Saya mau membuat sebuah solusi SSO menggunakan Jasig CAS. Ada, sih, versi lain seperti SUN CAS, Google Accounts, atau WSO2 Identity Provider. Tapi, saya memilih CAS karena sudah lama digunakan di UI dan saya malas mencari yang lain.

Berhubung tulisan ini panjang, langsung saja saya berikan asumsi berikut:

  • Debian Strecth masih kosong.
  • CAS berdiri sendiri (standalone) dengan Jetty.
  • Sertifikat SSL sudah ditandatangani oleh pihak ketiga.
  • Iman yang teguh.

Langsung saja persiapan sistem.

Persiapan Sistem

Sebelum memasang CAS, persiapkan sistem terlebih dahulu.

Memasang JDK 8

Saya percaya isi lisensi, lebih baik dilewati saja:

Agar dapat memasang sertifikat dari Webupd8, pastikan untuk memasang dirmgr (khusus Stretch):

Tambahkan repo Pemasang Oracle Java.

Pasang Oracle JDK8 dan paket unlimited JCE. Paket JCE berfungsi untuk mengaktifkan fungsi enkripsi yang lebih tinggi dari standar enkripsi yang disediakan oleh Oracle Java.

Selesai untuk Java.

Menyiapkan Direktori yang Perlu

Sayangnya, sebelum CAS terpasang, ada yang harus dipersiapkan. Hal ini karena konfigurasi CAS masih terkode langsung dan tersebar di konfigurasi sehingga lebih baik untuk pemula mengikuti direktori konfigurasi standar.

Yang saya maksud adalah membuat direktori /etc/cas yang dimiliki oleh pengguna. Bisa saja dijalankan sebagai root langsung. Namun, lebih baik Anda berhenti membaca tulisan ini dan cari pekerjaan yang lebih cocok daripada sysadmin.

Penambahan ekstra keamanan sehingga hanya bisa diakses oleh pengguna yang menjalankan CAS.

Memasang Sertifikat SSL

Untuk sertifikat yang ditandatangani sendiri, silakan baca panduan yang sudah disediakan pada Daftar Bacaan. Serius, deh. Pelit sekali Anda untuk bahkan  tidak mau menyediakan waktu untuk membuat sertifikat SSL Let’s Encrypt dengan certbot.

Hal yang perlu dilakukan adalah mengonversi PEM menjadi PKCS12 yang siap untuk diimpor ke dalam format keystore Java.

Ubah format PEM ke format PKCS12. Buat sembarang sandi karena keytool Java (JKS) tidak bisa mengimpor kunci tanpa sandi.

Terakhir, ubah dari PKCS12 ke JKS. Lihat, berkas dan kunci masing-masing saya buat dengan sandi yang berbeda. Jangan lupa disesuaikan pada berkas konfigurasi.

Ubah perizinan berkas thekeystore dan pindahkan ke direktori /etc/cas.

Selanjutnya memasang CAS.

Memasang Overlay CAS

CAS versi terbaru (5.1.x) memecah paket-paket modulnya dalam banyak modul. CAS menggunakan perkakas pembangun Java untuk membungkus dan memaket modul sesuai dengan kebutuh pengguna. Jenis pemaketan tersebut dinamakan overlays. Ada dua jenis yang didukung yakni Maven dan Gradle. Saya memilih Gradle karena Maven lebih gampang dipasang.

Mengunduh Overlay CAS

Unduh dan ekstraksi overlay untuk Gradle:

Mengonfigurasi Overlay CAS

Pada gradle.properties saya mengubah versi Spring Boot ke yang terbaru:

Pada etc/cas/config/application.yml tambahkan:

Pada baris ke-5 etc/cas/config/log4j2.xml ubah direktori log ke standar FHS (/var/log):

Pada cas/build.gradle ubah tomcat menjadi jetty:

Selanjutnya, jalankan perintah berikut untuk membangun paket yang dibutuhkan.

Menjalankan CAS

Berkas yang dihasilkan dari hasil konfigurasi ada di cas/build/libs/cas.war. Berkas ini merupakan sebuah paket aplikasi Web Java yang bisa dijalankan oleh kontainer Servlet apa pun. Namun, untuk keperluan kali ini, jalankan perintah:

Kalau sukses akan muncul di port 8443. Gunakan login casuser dan sandi Mellon untuk masuk.

Berhubung hari sudah subuh, saya berhenti di sini. Nanti selanjutnya tutorial akan lanjut kepada konfigurasi CAS.

Bacaan Lebih Lanjut

Membuat Entitas CRUH pada Spring JPA

Membuat Entitas CRUH pada Spring JPA

Operasi basis data biasa mengenal akronim CRUD yang berarti Create (Buat), Read (Baca), Update (Modifikasi), dan Delete (Hapus). Operasi-operasi ini lazim diterapkan pada bisnis sehari-hari. Namun, pada beberapa data kritikal, operasi hapus tidak boleh benar-benar dilakukan. Yang dilakukan hanya mengubah agar data tersebut tidak terlihat/aktif di aplikasi, namun secara fisik masih ada di basisdata.

JPA Pada Umumnya

Sebagai contoh, misalkan ada kelas entitas akun yang biasa dibuat oleh orang.

Pada kelas Account.java seperti biasa kita membuat kolom-kolom biasa. Lalu, misalkan dengan Spring Boot JPA, dibuatkan sebuah kelas Repository yang akan digunakan untuk melakukan operasi-operasi CRUD:

Saya akan menunjukkan selanjutnya bagaimana mengubah pola CRUD menjadi CRUH (Hide). Operasi CRUH hanya istilah saya saja yang artinya hanya menyembunyikan, bukan menghapus data (hapus-sembunyi).

CRUH dengan JPA

Salah satu solusi untuk operasi hapus-sembunyi adalah dengan menggunakan penanda. Kolom penanda ini digunakan untuk menyatakan data tersebut sudah terhapus. Sehingga, klien/aplikasi hanya akan mendapatkan data yang tidak ditandai. Solusi ini dapat dicapai dengan minimal melalui Spring JPA.

Pada JPA, yang diubah cukup hanya kelas entitas saja. Hal-hal yang diperlu dilakukan:

  • Ubah operasi hapus dengan menandai kolum penanda. Misalnya pada baris 4 operasi SQL hapus dimodifikasi dengan mengubah nilai deleted menjadi ‘1’.
  • Ubah operasi baca dengan mengambil data yang kolom penandanya belum diset. Misalnya pada baris 5, dicari deleted tidak sama dengan ‘1’.
  • Buat sebuah kolom penanda. Misalnya pada baris 13, ditambahkan kolom deleted. 
  • Pada baris 12 dibuatkan sebuah anotasi @JsonIgnore agar kolom ini tidak muncul pada akses data melalui Repository. Jadi, kolom ini benar-benar transparan.
  • Jangan lupa diinisialisasi data deleted pada konstruktor.

Semoga bermanfaat.