Understanding How Casbin Matching Works in Detail
Bu yazıda, Casbin kütüphanesini kullanarak RBAC'nin tasarımını ve uygulanmasını açıklayacağım. Birden fazla kaynak hiyerarşileri ve üst düzeylerden izinleri miras alan rollerle ilgilenen bir SaaS platformu için, Casbin performanslı bir alternatif sunar.
RBAC'ye Giriş
RBAC, bireylerin sahip olduğu rolleri temel alarak kaynaklara erişimi kısıtlayan bir yöntemdir. Hiyerarşik RBAC'in nasıl çalıştığını daha iyi anlamak için, bir sonraki bölümde Azure'un RBAC sistemi üzerine bir göz atalım ve ardından benzer bir sistem uygulamaya çalışalım.
Azure'un Hiyerarşik RBAC'ını Anlamak
Azure'da tüm kaynaklar için Sahip adında bir rol bulunmaktadır. Eğer abonelik düzeyinde Sahip rolüne atanmışsam, bu, o abonelik altındaki tüm kaynak gruplarının ve kaynakların Sahibi olduğum anlamına gelir. Eğer kaynak grubu düzeyinde Sahip'imse, bu durumda o kaynak grubu altındaki tüm kaynakların Sahibi olduğum anlamına gelir.
Bu resim, abonelik düzeyinde Sahip erişimine sahip olduğumu gösteriyor. 
Bu Abonelik altındaki bir Kaynak Grubunun IAM'sini kontrol ettiğimde, abonelikten Sahip erişimini miras aldığımı görebilirsiniz. 
Yani, Azure'nın RBAC'sinin hiyerarşik olduğu böyle. Çoğu kurumsal yazılım, kaynak düzeylerinin hiyerarşik doğası nedeniyle hiyerarşik RBAC kullanır. Bu eğitimde, Casbin kullanarak benzer bir sistem uygulamaya çalışacağız.
Casbin Nasıl Çalışır?
Uygulamaya dalmadan önce, Casbin'in ne olduğunu ve yüksek düzeyde nasıl işlediğini anlamak önemlidir. Bu anlayış, her Rol Tabanlı Erişim Kontrol (RBAC) sisteminin belirli gereksinimlere göre değişebilmesi nedeniyle gereklidir. Casbin'in çalışma şeklini kavrayarak, modeli etkili bir şekilde ince ayar yapabiliriz.
ACL Nedir?
ACL, Erişim Kontrol Listesi anlamına gelir. Kullanıcıların eylemlere ve eylemlerin kaynaklara eşleştirildiği bir yöntemdir.
Model tanımı
Bir ACL modelinin basit bir örneğini düşünelim.
[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
request_definition, sistemin sorgu şablonudur. Örneğin,
alice, write, data1isteği, "Konu Alice, nesne 'data1' üzerinde 'write' eylemini gerçekleştirebilir mi?" şeklinde yorumlanabilir.policy_definition, sistemin atama şablonudur. Örneğin,
alice, write, data1politikası oluşturarak, konu Alice'e nesne 'data1' üzerinde 'write' eylemini gerçekleştirme izni atamış olursunuz.policy_effect, politikanın etkisini tanımlar.
matchers bölümünde, istek,
r.sub == p.sub && r.obj == p.obj && r.act == p.actkoşulları kullanılarak politikayla eşleştirilir.
Şimdi modeli Casbin düzenleyicisinde test edelim
Düzenleyiciyi açın ve yukarıdaki modeli Model düzenleyicisine yapıştırın.
Aşağıdakileri Politika düzenleyicisine yapıştırın:
p, alice, read, data1
p, bob, write, data2
ve aşağıdakileri İstek düzenleyicisine yapıştırın:
alice, read, data1
Sonuç şu şekilde olacaktır:
true
ACL modelinin, politika ve istek eşleştirmenin görsel temsili
RBAC nedir?
RBAC, Rol Tabanlı Erişim Kontrolü anlamına gelir. RBAC'de, bir kullanıcıya bir kaynak için bir rol atanır ve bir rol isteğe bağlı eylemler içerebilir. İstek daha sonra kullanıcının kaynak üzerinde eylemi gerçekleştirme iznine sahip olup olmadığını kontrol eder.
Model tanımı
Basit bir RBAC modeli örneği düşünelim:
[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
- role_definition, istek nesnesini politika nesnesiyle karşılaştırmak için bir Grafiği kullanan bir graf ilişki oluşturucusudur.
Şimdi modeli Casbin düzenleyicisinde test edelim
Düzenleyiciyi açın ve yukarıdaki modeli Model düzenleyicisine yapıştırın.
Aşağıdakileri Politika düzenleyicisine yapıştırın:
p, alice, reader, data1
p, bob, owner, data2
g, reader, read
g, owner, read
g, owner, write
ve aşağıdakileri İstek düzenleyicisine yapıştırın:
alice, read, data1
alice, write, data1
bob, write, data2
bob, read, data2
bob, write, data1
Sonuç şu şekilde olacaktır:
true
false
true
true
false
RBAC modelinin, politika ve istek eşleştirmenin görsel temsili
g - Rol-eylem eşleştirme tablosu, rolü eylemle eşleyen bir Grafik içerir. Bu Grafik, aşağıdaki politikada gösterildiği gibi, bir kenarlar listesi olarak kodlanabilir; bu, bir Grafiği temsil etmenin yaygın bir yoludur:
g, reader, read
g, owner, read
g, owner, write
p, == operatörü kullanılarak karşılaştırılabilen normal bir politika belirtir. g, Grafik tabanlı bir karşılaştırma fonksiyonudur. g, g2, g3, ... gibi sayısal bir sonek ekleyerek birden fazla Grafik karşılaştırıcı tanımlayabilirsiniz.
Hiyerarşik RBAC nedir?
Hiyerarşik RBAC'ta, birden fazla türde kaynak bulunmaktadır ve kaynak türleri arasında bir kalıtım ilişkisi vardır. Örneğin, "abonelik" bir tür ve "kaynakGrup" başka bir türdür. Subscription türündeki bir sub1, ResourceGroup türündeki birden çok kaynakGrup (rg1, rg2) içerebilir.
Kaynak hiyerarşisine benzer şekilde, iki tür rol ve eylem bulunacaktır: Abonelik rolleri ve eylemleri, ve KaynakGrup rolleri ve eylemleri. Abonelik rolü ile KaynakGrup rolü arasında keyfi bir ilişki vardır. Örneğin, bir Abonelik Rolü sub-owner'ı düşünün. Bu rol, rg-owner adında bir Kaynak Grubu Rolü tarafından devralınır; bu, eğer Abonelik sub1 üzerinde sub-owner rolüne atanırsam, o zaman otomatik olarak rg1 ve rg2 üzerinde rg-owner rolünü de elde edeceğim anlamına gelir.
Model tanımı
Hiyerarşik RBAC modelinin basit bir örneğini ele alalım:
[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)
- role_definition, istek nesnesini politika nesnesiyle karşılaştırmak için bir Graf kullanan bir graf ilişki oluşturucusudur.
Şimdi modeli Casbin düzenleyicisinde test edelim
Düzenleyiciyi açın ve yukarıdaki modeli Model düzenleyicisine yapıştırın.
Aşağıdakini Politika düzenleyicisine yapıştırın:
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
Ve aşağıdakini İstek düzenleyicisine yapıştırın:
alice, rg-read, rg1
Sonuç şu şekilde olacaktır:
true
RBAC modelinin, politikasının ve istek eşleştirmenin görsel temsili
g - Rolden (Eylem, Rol) Eşlemesine tablo, rolden eylem, rol eşlemesine grafik eşleme içerir. Bu grafik, politikada gösterildiği gibi, bir dizi kenar olarak kodlanabilir, bu da bir grafiği temsil etmenin yaygın bir yoludur:
// 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
g2 - Aboneye RG Eşlemesi tablosu, aboneyi resourceGroup'a eşleyen bir grafik içerir:
// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2
Konu Eşleştirmenin Görsel Temsili
Eylem Eşleştirmenin Görsel Temsili
Nesne Eşleştirmenin Görsel Temsili
Bir istek Casbin'e gönderildiğinde, bu eşleşme tüm politikalar için gerçekleşir. En az bir politika eşleşiyorsa, isteğin sonucu doğrudur. Hiçbir politika isteğe uymuyorsa, sonuç yanlıştır.
Sonuç
Bu eğitimde, farklı yetkilendirme modellerinin nasıl çalıştığını ve Casbin kullanarak nasıl modellenebileceğini öğrendik. Bu eğitimin ikinci kısmında, bunu bir demo Spring Boot Uygulamasında uygulayacağız ve API'leri Casbin kullanarak güvence altına alacağız.