PostgreSQL Mengungguli OpenFGA: Bagaimana Satu Tim Merevolusi Sistem Otorisasi

Tim Komunitas BigGo
PostgreSQL Mengungguli OpenFGA: Bagaimana Satu Tim Merevolusi Sistem Otorisasi

PostgreSQL Mengungguli OpenFGA: Bagaimana Satu Tim Merevolusi Sistem Otorisasi

Dalam lanskap pengembangan perangkat lunak yang terus berkembang, sistem otorisasi telah menjadi penjaga diam-diam dari aplikasi kita. Sementara solusi otentikasi telah menjadi standar, otorisasi tetap menjadi perbatasan liar di mana para pengembang terus berjuang melawan kompleksitas, skalabilitas, dan masalah sinkronisasi. Diskusi komunitas baru-baru ini mengenai keputusan satu tim untuk menulis ulang implementasi OpenFGA mereka dalam PostgreSQL murni telah memicu perdebatan sengit tentang masa depan sistem otorisasi.

Mimpi Buruk Sinkronisasi yang Memicu Inovasi

Tantangan inti yang mendorong pergeseran arsitektural ini adalah apa yang oleh para pengembang disebut masalah sinkronisasi. Ketika data otorisasi berada dalam sistem terpisah dari basis data aplikasi utama Anda, setiap perubahan menjadi mimpi buruk koordinasi. Menambahkan pengguna, organisasi, atau sumber daya baru memerlukan pembaruan segera ke kedua sistem, menciptakan ketergantungan yang rapuh dan celah keamanan potensial.

Satu komentator dengan sempurna menangkap masalah mendasar dengan sistem otorisasi yang terinspirasi Zanzibar:

Ini adalah masalah mendasar dengan semua sistem otorisasi yang terinspirasi Zanzibar yang mengharuskan sentralisasi semua data otorisasi.

Tim tersebut menemukan bahwa memelihara dua penyimpanan data terpisah berarti mereka tidak dapat memanfaatkan fitur native PostgreSQL seperti penghapusan berjenjang, transaksi, dan batasan kunci asing. Ketika persyaratan kepatuhan GDPR memaksa mereka untuk menerapkan penghapusan akun pengguna, mereka dihadapkan pada realisasi menyakitkan bahwa sistem otorisasi mereka tidak dapat melakukan penghapusan berjenjang secara otomatis seperti yang dapat dilakukan basis data utama mereka.

Teka-teki Pencarian dan Otorisasi

Poin diskusi kritis lainnya muncul seputar tantangan menggabungkan otorisasi dengan fungsionalitas pencarian. Ketika Anda perlu memberikan hasil yang dipaginasi dan difilter berdasarkan izin pengguna, memiliki data otorisasi dalam sistem terpisah menciptakan hambatan kinerja dan kompleksitas yang signifikan.

Pencarian ingin menjadi hal sendiri, dan begitu pula authz. Tolong beritahu saya bagaimana saya seharusnya mendapatkan daftar hasil yang diotorisasi dan dipaginasi? Anda harus memfilter atau membuat layanan pencarian memanggil layanan authz. Hidup lebih mudah ketika basis data utama dapat menangani semuanya.

Komentar ini menyoroti ketegangan arsitektural antara layanan khusus dan sistem terpadu. Komunitas mendiskusikan berbagai solusi, dari pendekatan pra-penyaringan dan pasca-penyaringan hingga tampilan materialisasi yang lebih canggih yang mendinormalisasi data otorisasi kembali ke dalam basis data aplikasi.

Beberapa pengembang berbagi pengalaman mereka dengan mempertahankan tabel pemetaan untuk pencarian izin cepat, hanya untuk menemukan bahwa pembaruan data menjadi semakin berantakan seiring waktu. Konsensus tampaknya adalah bahwa sementara layanan otorisasi eksternal menawarkan manfaat teoretis, biaya implementasi praktis sering kali lebih besar daripada keuntungannya untuk aplikasi yang sedang berkembang.

Perbandingan Pendekatan Otorisasi

Pendekatan Nama Lengkap Karakteristik Utama Kasus Penggunaan Terbaik
RBAC Role-Based Access Control Pengguna memiliki peran dengan izin yang telah ditentukan sebelumnya Aplikasi sederhana dengan hierarki peran yang jelas
PBAC Policy-Based Access Control Kebijakan JSON/YAML mendefinisikan kriteria akses Tata kelola API, sistem enterprise
ABAC Attribute-Based Access Control Akses berdasarkan atribut pengguna/resource/lingkungan Kebutuhan keamanan yang terperinci
ReBAC Relationship-Based Access Control Akses berdasarkan hubungan antar entitas Aplikasi kolaboratif seperti Google Drive

Solusi PostgreSQL: Kesederhanaan Bertemu Kekuatan

Keputusan tim untuk mengimplementasikan logika otorisasi mereka langsung di PostgreSQL mewakili pendekatan kembali-ke-dasar yang menantang ortodoksi mikrolayanan modern. Dengan membuat tabel authz_model untuk mendefinisikan skema otorisasi mereka dan tampilan authz_relationship yang menghitung tuple sesuai permintaan dari tabel relasional yang ada, mereka menghilangkan masalah sinkronisasi sepenuhnya.

Fungsi check_permission mereka menjadi tulang punggung sistem, secara rekursif melintasi grafik otorisasi yang didefinisikan dalam model mereka. Pendekatan ini memungkinkan mereka untuk mempertahankan filosofi kontrol akses berbasis hubungan sambil memanfaatkan dukungan transaksi yang kuat dan fitur integritas data PostgreSQL.

Reaksi komunitas terhadap pendekatan ini beragam tetapi umumnya positif. Beberapa pengembang mengungkapkan kejutan pada efektivitas menyimpan logika dalam basis data, mencatat bahwa selalu menyegarkan untuk melihat ketika itu bisa bekerja meskipun tren saat ini lebih menyukai layanan eksternal. Yang lain meminta pembaruan tentang kinerja jangka panjang, terutama seputar overhead komputasi dari menghasilkan hubungan otorisasi sesuai permintaan.

Komponen Implementasi PostgreSQL

  • Tabel authz_model: Menyimpan definisi skema otorisasi dengan aturan tipe, relasi, dan pewarisan
  • View authz_relationship: Menghitung tupel relasi secara on-demand dari tabel database yang ada
  • Fungsi check_permission: Mengevaluasi kueri otorisasi secara rekursif terhadap model
  • Skrip utilitas: Mengelola migrasi skema dan alur kerja pengembangan

Masa Depan Sistem Otorisasi

Studi kasus ini mengajukan pertanyaan penting tentang kapan menggunakan layanan otorisasi khusus versus solusi basis data terintegrasi. Untuk aplikasi kecil hingga menengah, pendekatan PostgreSQL menawarkan keunggulan menarik dalam kesederhanaan dan konsistensi data. Namun, ketika aplikasi berkembang ke basis pengguna besar dengan struktur izin yang kompleks, kemampuan penskalaan khusus dari sistem seperti OpenFGA dan SpiceDB mungkin menjadi diperlukan.

Diskusi ini juga mengungkap solusi baru yang menjembatani kedua dunia, seperti pembungkus data asing yang memungkinkan PostgreSQL secara native JOIN terhadap layanan otorisasi eksternal, dan pendekatan materialisasi yang menyinkronkan data otorisasi kembali ke basis data aplikasi.

Yang jelas dari percakapan komunitas adalah bahwa tidak ada solusi satu-untuk-semua untuk otorisasi. Pendekatan optimal tergantung pada faktor seperti skala aplikasi, ukuran tim, persyaratan kepatuhan, dan infrastruktur yang ada. Seperti yang dicatat oleh satu pengembang, kemampuan untuk beradaptasi dengan model otorisasi dengan cepat dalam lingkungan yang gesit menjadi semakin penting.

Penulisan ulang yang berhasil oleh tim di PostgreSQL menunjukkan bahwa kadang-kadang solusi paling inovatif juga yang paling sederhana. Dengan mundur dari sistem terdistribusi yang kompleks dan memanfaatkan fitur kuat yang sudah tersedia dalam basis data mereka, mereka menciptakan sistem otorisasi yang lebih mudah dipelihara dan lebih andal—membuktikan bahwa dalam dunia pengembangan perangkat lunak, kadang-kadang cara terbaik untuk maju adalah dengan mengambil langkah mundur.

Referensi: How we rewrote OpenFGA in pure Postgres