Project Asas

Programmer kalo nggak baper, maka dia tidak mencintai profesinya. Nah, apa yang bikin saya baper? Tidak lain dan tidak bukan adalah pekerjaan kantor. Karena irama kerjanya yang cepat, kantor saya ini kurang menyukai gaya berpikir mendalam yang sudah mengakar dalam pribadi saya. Karena itulah, beberapa arsitektur sistem yang dibangun seringkali kurang dipikirkan dengan matang. Kalau diperdebatkan sih sering malah bisa sampai berjam-jam. Namun, jarang sekali dalam sesi-sesi debat itu mereka memberi waktu para tukang debat untuk istirahat, tidur, rapat lagi tiga hari kemudian setalah mengendapkan permasalahan yang sedang dihadapi. Karena itulah, saya melihat solusi-solusi yang dibangun tidak tajam, tidak sangkil dan mangkus istilahnya. Tidak ada solusi yang ideal memang. Tapi, seandainya kita berpikir sedikit lebih dalam saja, maka kita dapat menghasilkan arsitektur yang jauh lebih murah untuk dibangun dan boleh jadi lebih mudah untuk dikembangkan di masa depan. Bukan berarti saya tidak terpengaruh oleh irama kerja cepat ini, dan bukan pula berarti rancangan saya yang paling yahud. Tapi, setiap kali saya mencoba mengikuti irama kerja ini, yang terjadi adalah saya uring-uringan dan frustrasi. Saya membenci apa yang saya kerjakan.

Nah, di antara hal yang selalu bikin saya uring-uringan setiap kali melihatnya adalah soal IAM atau Identity and Account Management. Idealnya, sebelum merancang atau membongkar ulang si sistem ini, para pengembangnya belajar dulu untuk mendalami OAuth, OpenID Connect, ACL, RBAC, dan ABAC. Tapi, ternyata tidak begitu kenyataannya. Setiap kali mau membongkar, kita asal bongkar saja, yang penting bisa dipakai untuk kebutuhan yang baru. Ya, begitulah akibatnya. Akhirnya, banyak sekali hal-hal tidak penting yang kemudian masuk mengganggu cara kerja sistem ini. Akhirnya, pengguna yang kena getahnya. Si Admin kalau mau mengatur permissions untuk orang-orang yang memakai sistem-nya AccelByte, susahnya minta ampun. Memang sih, mengatur jalur akses untuk seluruh pemakai sistem itu pada dasarnya tidak mudah, apalagi jika organisasinya besar dan memiliki banyak divisi. Itulah sebabnya! Hal yang pada dasarnya susah kok mikirnya serampangan, ya ambyar!

Asas itu kan artinya fondasi atau dasar. Nah, banyak sekali sistem yang saya lihat, itu tidak bisa lepas dari manajemen pengguna. Github, Facebook, Google, Tokopedia, Gojek, Grab, Shopee, dan semua produk-produk yang dipakai banyak orang dan berbasis daring semuanya masing-masing mempunyai manajemen pengguna. Ini artinya, manajemen pengguna adalah kebutuhan dasar untuk sistem yang digunakan oleh banyak orang, utamanya di mana para pengguna memiliki peran yang berbeda-beda dalam sistem tersebut.

Yang kedua, ketika kita menambahkan layanan baru di atas sistem yang sudah ada, layanan baru ini akan mengacu dan tergantung pada manajemen pengguna. Artinya, manajemen pengguna akan merasuk ke dalam keseluruhan sistem dan tidak bisa lepas darinya. Sekali kita salah dalam merancang, maka selanjutnya kita akan harus membayar lebih mahal dalam pengembangan layanan-layanan baru.

Tadi saya bilang kalau saya ingin mengembangkan kemampuan memecahkan masalah saya dalam latihan-latihan praktis. Nah, manajemen pengguna ini ada dua bagian penting kalau boleh saya bilang. Bagian pertama adalah otentikasi dan otorisasi. Bagian ini mengatur bagaimana pengguna membuktikan bahwa dirinya memang boleh mengakses sistem, dan memang benar bahwa dia adalah pemilik identitas yang diklaimnya. Di dunia web, otentikasi dan otorisasi adalah bagian yang sudah matang. Standar yang banyak dipakai di antaranya adalah OAuth 2.0 dan OpenID Connect. Ada juga SAML, tapi saya kurang familiar. Tidak menarik untuk mengulik sesuatu yang standarnya sudah pasti dan sangat rumit tapi kaku. Tidak ada kreatif-kreatifnya sama sekali. Bagian yang kedua masih erat hubungannya dengan bagian pertama.

Bagian kedua adalah soal access control. Intinya, bagian ini mengatur soal siapa boleh berbuat apa pada kondisi apa. Nah, bagian ini menurut saya asyik untuk direnungkan dibahas. Soalnya, walaupun sudah ada standarnya, tapi tiap solusi punya caranya sendiri untuk menyelesaikan masalah. AWS ada sendiri, Azure juga punya, Ory punya Keto, Auth0 sudah ada. Menariknya lagi, pembuat solusi-solusi itu bilang bahwa pengguna memang harus berpusing ria kalau harus berurusan dengan access control. Artinya, solusi yang nanti bakalan saya hasilkan boleh jadi akan jadi solusi ecek-ecek yang hanya cocok digunakan untuk kasus tertentu. Tapi, tetap selesai saya ngulik soal ini, saya jadi punya kemampuan analisis yang jauh lebih tajam ketika menghadapi hal yang sama.

Katakanlah ada sebuah toko daring yang berjualan musik, film, dan buku digital. Di antara buku digital yang dijual, ternyata ada juga yang gratis. Tapi, yang bisa memperolehnya cuma pelanggan yang terverifikasi saja. Nah, ternyata toko kita itu juga menyediakan lapak-lapak buat penjual-penjual yang lain. Penjual ini ingin melihat data-data pembelian dagangan, tapi hanya boleh melihat data dari barang yang dijualnya saja. Di toko itu, ada juga pegawai yang bertugas membuat resensi film. Tapi, dia cuma boleh menonton film yang dia ditugaskan untuk membuat resensinya. Katakanlah juga, pegawai lain yang bertugas sebagai admin yang bertugas membuat promo diskon film dan buku gratis. Pegawai ini sekaligus juga pelanggan. Si toko daring tidak boleh kebingungan ketika kapan si admin ini berperan sebagai pelanggan, kapan si admin berperan sebagai admin. Masalah-masalah inilah yang dicoba diselesaikan oleh access control. Ternyata, mengatur soal "siapa boleh berbuat apa pada kondisi apa" bukanlah soal yang mudah bukan?

Masalah access control ini sudah ada sejak lama, sehingga sumber-sumbernya sudah sangat banyak. Kata kuncinya pun khas, sehingga gampang dicari melalui mesin pencari. Tinggal ketik saja ACL, RBAC, atau ABAC sudah ketemu semua sumber-sumber bermutu yang berjibun. Karena saya ingin belajar memecahkan masalah dengan baik, maka belajar dari ulama-ulama terdahulu itu wajib. Kalau tidak, nanti akan terjebak pada kesalahan yang sama dan mengalami kesulitan yang sama.

Tapi, sebelum terperosok dalam di tiap-tiap solusinya, harus cermat juga memperhatikan setiap konsep itu ingin memecahkan masalah apa, dan pendekatannya bagaimana. Misalnya, kalau kita terlalu dekat dengan badan standar macam NIST, wajar kalau kita mendapatkan sumber-sumber dengan solusi yang luwes untuk berbagai kebutuhan, tapi sangat rumit dan susah dipahami. Namanya banyak orang ngobrol dan masing-masing minta keinginannya dituruti ya begitu. Kalau kita mendapatkan solusi dari perusahaan besar, kadang kita mendapatkan solusi yang tidak lepas dari sejarah masa lalu, alias solusi yang dikembangkan dari sistem sebelumnya. Ya kalau tidak, akan sangat mahal untuk memindahkan semua infrastrukturnya ke sistem yang baru. Soalnya, access control ini ibarat urat nadinya perangkat lunak dengan banyak pengguna. Apalagi kalau masing-masing pengguna mempunyai peran yang berbeda-beda.