Understanding How Casbin Matching Works in Detail

Dalam catatan ini, saya akan menerangkan reka bentuk dan pelaksanaan RBAC menggunakan pustaka Casbin. Bagi platform SaaS yang mengendalikan pelbagai hierarki sumber dan peranan yang mewarisi kebenaran dari tahap yang lebih tinggi, Casbin menawarkan alternatif yang berprestasi untuk dipertimbangkan.

Pengenalan kepada RBAC

RBAC ialah kaedah mengehadkan akses kepada sumber berdasarkan peranan yang dipegang oleh individu. Untuk lebih memahami bagaimana RBAC hierarki berfungsi, mari kita lihat sistem RBAC Azure di bahagian seterusnya dan kemudian cuba melaksanakan sistem yang serupa.

Memahami RBAC Hierarki Azure

Terdapat peranan yang dipanggil Pemilik untuk semua sumber di Azure. Andaikan jika saya mempunyai peranan Pemilik yang diberikan kepada saya pada tahap langganan, itu bermakna saya adalah Pemilik bagi semua kumpulan sumber dan sumber di bawah langganan tersebut. Jika saya mempunyai Pemilik pada tahap kumpulan sumber, maka saya adalah Pemilik bagi semua sumber di bawah kumpulan sumber tersebut.

Gambar ini menunjukkan bahawa saya mempunyai akses Pemilik pada tahap langganan.

Apabila saya menyemak IAM bagi Kumpulan Sumber di bawah Langganan ini, anda dapat melihat bahawa saya telah mewarisi akses Pemilik dari langganan.

Jadi, beginilah hierarki RBAC di Azure. Kebanyakan perisian perusahaan menggunakan RBAC hierarki kerana sifat hierarki Dalam tutorial ini, kita akan cuba melaksanakan sistem yang serupa menggunakan Casbin.

Bagaimana Cara Kerja Casbin?

Sebelum menyelam ke dalam pelaksanaan, penting untuk memahami apa itu Casbin dan bagaimana ia berfungsi pada tahap tinggi. Pemahaman ini diperlukan kerana setiap sistem Kontrol Akses Berbasis Peran (RBAC) mungkin berbeza berdasarkan keperluan khusus. Dengan memahami cara kerja Casbin, kita dapat menyesuaikan model dengan efektif.

Apakah ACL?

ACL bermaksud Senarai Kawalan Akses. Ia adalah kaedah di mana pengguna dipetakan ke tindakan dan tindakan ke sumber.

Definisi model

Mari kita pertimbangkan contoh mudah 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 pertanyaan sistem. Sebagai contoh, permintaan alice, write, data1 boleh ditafsirkan sebagai "Bolehkah subjek Alice melakukan tindakan 'write' pada objek 'data1'?"

2. policy_definition adalah templat tugasan sistem. Sebagai contoh, dengan membuat polisi alice, write, data1, anda memberikan kebenaran kepada subjek Alice untuk melakukan tindakan 'write' pada objek 'data1'.

3. policy_effect mentakrifkan kesan polisi.

4. Di bahagian matchers, permintaan dipadankan dengan polisi menggunakan syarat r.sub == p.sub && r.obj == p.obj && r.act == p.act.

Sekarang mari kita uji model pada editor Casbin

Buka editor dan tampal model di atas dalam Model editor.

Tampal yang berikut dalam editor Polisi:

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

dan yang berikut dalam editor Permintaan:

alice, read, data1

Hasilnya akan menjadi:

true

Perwakilan visual model ACL, polisi, dan padanan permintaan

Apakah itu RBAC?

RBAC bermaksud Kawalan Akses Berbasis Peranan. Dalam RBAC, pengguna diberikan peranan untuk sumber, dan peranan boleh mengandungi tindakan sewenang-wenangnya. Permintaan kemudian menyemak jika pengguna mempunyai kebenaran untuk melaksanakan tindakan pada sumber.

Definisi model

Mari kita pertimbangkan contoh mudah model 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) && r.obj == p.obj

1. role_definition ialah pembina hubungan graf yang menggunakan Graf untuk membandingkan objek permintaan dengan objek polisi.

Sekarang mari kita uji model ini pada editor Casbin

Buka editor dan tampal model di atas dalam Editor Model.

Tampal yang berikut dalam Editor Polisi:

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

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

dan yang berikut dalam Editor Permintaan:

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

Hasilnya akan menjadi:

true
false
true
true
false

Perwakilan visual model RBAC, polisi, dan padanan permintaan

Jadual g - Pemetaan peranan ke tindakan mempunyai pemetaan Graf yang memetakan peranan ke tindakan. Graf ini boleh dikodkan sebagai senarai tepi, seperti yang ditunjukkan dalam polisi yang merupakan cara biasa untuk mewakili Graf:

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

maklumat

p menunjukkan polisi biasa yang boleh dibandingkan menggunakan operator ==. g adalah fungsi perbandingan berdasarkan Graf. Anda boleh menentukan pelbagai pembanding Graf dengan menambah sufiks angka seperti g, g2, g3, ... dan seterusnya.

Apakah RBAC Berhierarki?

Dalam RBAC Berhierarki, terdapat lebih dari satu jenis sumber dan terdapat hubungan warisan antara jenis sumber tersebut. Contohnya, "subscription" adalah satu jenis dan "resourceGroup" adalah jenis lain. Sub1 jenis Subscription boleh mengandungi beberapa resourceGroups (rg1, rg2) jenis ResourceGroup.

Serupa dengan hierarki sumber, akan terdapat dua jenis peranan dan tindakan: Peranan dan tindakan Subscription, dan Peranan dan tindakan ResourceGroup. Terdapat hubungan sewenang-wenangnya antara peranan Subscription dan peranan ResourceGroup. Sebagai contoh, pertimbangkan Peranan Langganan sub-owner. Peranan ini diwarisi oleh Peranan Kumpulan Sumber rg-owner, yang bermaksud jika saya diberikan peranan sub-owner pada Langganan sub1, maka saya secara automatik juga akan mendapat peranan rg-owner pada rg1 dan rg2.

Definisi model

Mari kita ambil contoh mudah 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 pembina hubungan graf yang menggunakan Graf untuk membandingkan objek permintaan dengan objek polisi.

Sekarang mari kita uji model ini pada editor Casbin

Buka editor dan tampal model di atas dalam Editor Model.

Tampal yang berikut dalam Editor Polisi:

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 tampal yang berikut dalam Editor Permintaan:

alice, rg-read, rg1

Hasilnya akan menjadi:

true

Perwakilan visual model RBAC, polisi, dan padanan permintaan

Jadual g - Pemetaan Peranan ke (Tindakan, Peranan) mempunyai graf yang memetakan peranan kepada pemetaan tindakan, peranan. Graf ini boleh dikodkan sebagai senarai tepi, seperti yang ditunjukkan dalam polisi, yang merupakan cara biasa untuk mewakili graf:

// 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

Jadual g2 - Pemetaan Sub ke RG mempunyai graf yang memetakan langganan kepada resourceGroup:

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

Perwakilan visual padanan subjek

Perwakilan visual padanan tindakan

Perwakilan visual padanan objek

maklumat

Apabila permintaan dihantar ke Casbin, pemadanan ini berlaku untuk semua dasar. Jika sekurang-kurangnya satu dasar padan, maka hasil permintaan adalah benar. Jika tiada dasar yang padan dengan permintaan, maka hasilnya adalah palsu.

Kesimpulan

Dalam tutorial ini, kita belajar tentang bagaimana model kebenaran yang berbeza berfungsi dan bagaimana ia dapat dimodelkan menggunakan Casbin. Dalam bahagian kedua tutorial ini, kita akan melaksanakan ini dalam aplikasi demo Spring Boot dan mengamankan API menggunakan Casbin.