Lewati ke konten utama

Understanding How Casbin Matching Works in Detail

Dalam postingan ini, saya akan menjelaskan desain dan implementasi RBAC menggunakan pustaka Casbin. Untuk platform SaaS yang menangani beberapa hierarki sumber daya dan peran yang mewarisi izin dari tingkat yang lebih tinggi, Casbin menawarkan alternatif yang performan untuk dipertimbangkan.

Pengenalan ke RBAC

RBAC adalah metode untuk membatasi akses ke sumber daya berdasarkan peran yang dimiliki individu. Untuk lebih memahami bagaimana RBAC hierarkis bekerja, mari kita lihat sistem RBAC Azure di bagian berikutnya dan kemudian mencoba mengimplementasikan sistem serupa.

Memahami RBAC Hierarkis Azure

Hierarki Azure

Ada peran yang disebut Pemilik untuk semua sumber daya di Azure. Misalkan jika saya memiliki peran Pemilik yang ditetapkan kepada saya pada tingkat langganan, itu berarti saya adalah Pemilik dari semua grup sumber daya dan sumber daya di bawah langganan tersebut. Jika saya memiliki Pemilik pada tingkat grup sumber daya, maka saya adalah Pemilik dari semua sumber daya di bawah grup sumber daya tersebut.

Gambar ini menunjukkan bahwa saya memiliki akses Pemilik pada tingkat langganan. Pemilik Langganan

Ketika saya memeriksa IAM dari Grup Sumber Daya di bawah Langganan ini, Anda dapat melihat bahwa saya mewarisi akses Pemilik dari langganan. Pemilik RG

Jadi, begini cara kerja RBAC di Azure yang bersifat hierarkis. Sebagian besar perangkat lunak perusahaan menggunakan RBAC hierarkis karena sifat hierarkis dari tingkat sumber daya. Dalam tutorial ini, kita akan mencoba mengimplementasikan sistem serupa menggunakan Casbin.

Bagaimana Cara Kerja Casbin?

Sebelum menyelam ke dalam implementasi, penting untuk memahami apa itu Casbin dan bagaimana ia berfungsi pada tingkat tinggi. Pemahaman ini diperlukan karena setiap sistem Kontrol Akses Berbasis Peran (RBAC) mungkin bervariasi berdasarkan persyaratan khusus. Dengan memahami cara kerja Casbin, kita dapat secara efektif menyesuaikan modelnya.

Apa itu ACL?

ACL adalah singkatan dari Access Control List. Ini adalah metode di mana pengguna dipetakan ke tindakan dan tindakan ke sumber daya.

Definisi model

Mari kita pertimbangkan contoh sederhana dari model ACL.

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act
  1. request_definition adalah templat kueri dari sistem. Misalnya, permintaan alice, write, data1 dapat diinterpretasikan sebagai "Dapatkah subjek Alice melakukan aksi 'write' pada objek 'data1'?"

  2. policy_definition adalah templat penetapan dari sistem. Misalnya, dengan membuat kebijakan alice, write, data1, Anda memberikan izin kepada subjek Alice untuk melakukan aksi 'write' pada objek 'data1'.

  3. policy_effect mendefinisikan efek dari kebijakan.

  4. Di bagian matchers, permintaan dipasangkan dengan kebijakan menggunakan kondisi r.sub == p.sub && r.obj == p.obj && r.act == p.act.

Sekarang mari kita uji model pada editor Casbin

Buka editor dan tempel model di atas ke dalam Model editor.

Tempelkan yang berikut ini di editor Kebijakan:

p, alice, read, data1
p, bob, write, data2

dan yang berikut ini di editor Permintaan:

alice, read, data1

Hasilnya akan menjadi:

true

Representasi visual dari model ACL, kebijakan, dan pencocokan permintaan

acl

Apa itu RBAC?

RBAC merupakan singkatan dari Role-Based Access Control. Dalam RBAC, seorang pengguna diberikan peran untuk suatu sumber daya, dan sebuah peran dapat mengandung tindakan sewenang-wenang. Permintaan kemudian memeriksa apakah pengguna memiliki izin untuk melakukan tindakan pada sumber daya tersebut.

Definisi model

Mari kita pertimbangkan contoh model RBAC yang sederhana:

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[role_definition]
g = _, _
g2 = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && g(p.act, r.act) && r.obj == p.obj
  1. role_definition adalah pembangun relasi grafik yang menggunakan Graf untuk membandingkan objek permintaan dengan objek kebijakan.

Sekarang mari kita uji model tersebut pada editor Casbin

Buka editor dan tempel model di atas ke dalam Model editor.

Tempelkan yang berikut ini di Policy editor:

p, alice, reader, data1
p, bob, owner, data2

g, reader, read
g, owner, read
g, owner, write

dan yang berikut ini di Request editor:

alice, read, data1
alice, write, data1
bob, write, data2
bob, read, data2
bob, write, data1

Hasilnya akan menjadi:

true
false
true
true
false

Representasi visual dari model RBAC, kebijakan, dan pencocokan permintaan

rbac

Tabel g - Pemetaan peran ke tindakan memiliki pemetaan Graf yang memetakan peran ke tindakan. Grafik ini dapat dikodekan sebagai daftar tepi, seperti yang ditunjukkan dalam kebijakan yang merupakan cara umum untuk mewakili Grafik:

g, reader, read
g, owner, read
g, owner, write
info

p menunjukkan kebijakan normal yang dapat dibandingkan menggunakan operator ==. g adalah fungsi perbandingan berbasis Grafik. Anda dapat mendefinisikan beberapa pembanding Grafik dengan menambahkan akhiran numerik seperti g, g2, g3, ... dan seterusnya.

Apa itu RBAC Hierarkis?

Dalam RBAC Hierarkis, terdapat lebih dari satu jenis sumber daya dan ada hubungan warisan antara jenis sumber daya tersebut. Misalnya, "subscription" adalah satu jenis dan "resourceGroup" adalah jenis lain. sub1 dari jenis Subscription dapat mengandung beberapa resourceGroups (rg1, rg2) dari jenis ResourceGroup.

Serupa dengan hierarki sumber daya, akan ada dua jenis peran dan tindakan: Peran dan tindakan Subscription, serta Peran dan tindakan ResourceGroup. Terdapat hubungan sewenang-wenang antara peran Subscription dan peran ResourceGroup. Misalnya, pertimbangkan peran Langganan sub-owner. Peran ini diwariskan oleh Peran Grup Sumber Daya rg-owner, yang berarti jika saya diberikan peran sub-owner pada Langganan sub1, maka saya juga secara otomatis mendapatkan peran rg-owner pada rg1 dan rg2.

Definisi model

Mari kita ambil contoh sederhana dari model Hierarchical RBAC:

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[role_definition]
g = _, _
g2 = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && g(p.act, r.act) && g2(p.obj, r.obj)
  1. role_definition adalah pembuat relasi grafik yang menggunakan Graf untuk membandingkan objek permintaan dengan objek kebijakan.

Sekarang mari kita uji model ini pada editor Casbin

Buka editor dan tempel model di atas ke dalam Model editor.

Tempelkan berikut ini di Policy editor:

p, alice, sub-reader, sub1
p, bob, rg-owner, rg2

// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write

// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write

// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner

// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2

Dan tempelkan berikut ini di Request editor:

alice, rg-read, rg1

Hasilnya akan menjadi:

true

Representasi visual dari model RBAC, kebijakan, dan pencocokan permintaan

hrbac

Tabel g - Pemetaan Peran ke (Tindakan, Peran) memiliki grafik yang memetakan peran ke pemetaan tindakan, peran. Grafik ini dapat dikodekan sebagai daftar tepi, seperti yang ditunjukkan dalam kebijakan, yang merupakan cara umum untuk merepresentasikan grafik:

// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write

// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write

// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner

Tabel g2 - Pemetaan Sub ke RG memiliki grafik yang memetakan langganan ke resourceGroup:

// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2

Representasi visual pencocokan subjek

hrbac-sub-match

Representasi visual pencocokan tindakan

hrbac-act-match

Representasi visual pencocokan objek

hrbac-obj-match

info

Ketika sebuah permintaan diajukan ke Casbin, proses pencocokan ini terjadi untuk semua kebijakan. Jika setidaknya satu kebijakan cocok, maka hasil dari permintaan tersebut adalah benar. Jika tidak ada kebijakan yang cocok dengan permintaan, maka hasilnya adalah salah.

Kesimpulan

Dalam tutorial ini, kita belajar tentang bagaimana model otorisasi yang berbeda bekerja dan bagaimana mereka dapat dimodelkan menggunakan Casbin. Di bagian kedua dari tutorial ini, kita akan mengimplementasikannya dalam aplikasi demo Spring Boot dan mengamankan API menggunakan Casbin.