Skip to content

Casbin

Resmi Depo: casbin/casbin: An authorization library that supports access control models like ACL, RBAC, ABAC in Golang (github.com)

Resmi Belgeler: Genel Bakış | Casbin

TIP

Bu makale bir Casbin giriş makalesi olarak kabul edilebilir. Daha detaylı bilgi için resmi web sitesini ziyaret edebilirsiniz.

Giriş

Bir sistemde backend geliştiriciler API izin yönetimi için sorumludur ve bu önemli miktarda çalışma gerektirir. Eğer her proje için sıfırdan yazılması gerekirse bu çok zaman alacaktır. Daha fazla kaynağa sahip büyük şirketler kendi yetkilendirme çerçevelerini geliştirmeyi tercih ederken küçük ve orta ölçekli şirketler bu geliştirme maliyetini karşılayamazlar. Bu nedenle açık kaynaklı yetkilendirme çerçeveleri onların ilk tercihi olur. Casbin böyle bir açık kaynaklı ve verimli erişim kontrol kütüphanesidir. Go dili ile geliştirilmiştir ve diğer popüler dilleri de destekler.

Casbin'in yalnızca bir erişim kontrol çerçevesi olduğunu unutmamak gerekir. Yalnızca erişim kontrolünden sorumludur erişim kimlik doğrulama mantığı Casbin tarafından yönetilmez. Yalnızca kullanıcılar ve roller arasındaki eşleme ilişkilerini depolar. Aşağıdaki erişim kontrol modellerini destekler:

  1. ACL (Erişim Kontrol Listesi)
  2. Süper kullanıcı ile ACL
  3. Kullanıcı Olmayan ACL: Kimlik doğrulama veya kullanıcı oturumu olmayan sistemler için özellikle kullanışlıdır.
  4. Kaynak Olmayan ACL: Bazı senaryolar yalnızca belirli kaynaklar yerine kaynak türleri için olabilir. Örneğin write-article, read-log gibi izinler. Belirli bir makale veya günlüğe erişimi kontrol etmez.
  5. RBAC (Role-Based Access Control - Role Dayalı Erişim Kontrolü)
  6. Kaynak Rolü Destekli RBAC: Kullanıcılar ve kaynaklar aynı anda rollere (veya gruplara) sahip olabilir.
  7. Domain/Kiracı Destekli RBAC: Kullanıcılar farklı domainler/kiracılar için farklı rol kümeleri ayarlayabilir.
  8. ABAC (Attribute-Based Access Control - Öznitelik Tabanlı Erişim Kontrolü): resource.Owner gibi sözdizimi ile özniteliklere erişimi destekler.
  9. RESTful: /res/*, /res/:id gibi yolları ve GET, POST, PUT, DELETE gibi HTTP metotlarını destekler.
  10. Reddetme Öncelikli: İzin verme ve reddetme yetkilendirmesini destekler. Reddetme izin vermeden önceliklidir.
  11. Öncelik: Politika kuralları öncelikleri belirlemek için sırayla uygulanır. Güvenlik duvarı kurallarına benzer.

Çalışma Prensibi

Casbin'de erişim kontrol modelleri PERM tabanlı yapılandırma dosyaları olarak soyutlanır. PERM; Policy (Politika), Effect (Etki), Request (İstek), Matcher (Eşleştirici) anlamına gelir. Projede yetkilendirme mekanizmasını değiştirirken yalnızca yapılandırma dosyasını değiştirmek yeterlidir. Normal bir Model yapılandırma dosyası içeriği aşağıdaki gibidir:

bash
[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

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

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act

Bu en basit ACL erişim kontrol modelidir.

Politika

Yapılandırma dosyasında politika tanımı bölümü:

[policy_definition]
p = sub, obj, act

p politika anlamına gelir ve başka karakterlerle değiştirilemez. sub subject (konu) anlamına gelir ve politika konusudur. obj object (nesne) anlamına gelir ve politika nesnesidir. act action (eylem) anlamına gelir.

p = sub, obj, act

Dördüncü bir alan olan eft de olabilir. Eğer atlanırsa varsayılan olarak eft allow'dır.

p=sub, obj, act, eft

Bu satır politikanın nasıl yazılacağını tanımlar ancak somut politika tanımı değildir. Aşağıda somut bir politika örneği verilmiştir:

p, jojo, cake, eat

p bir politika kuralı tanımı olduğunu temsil eder. jojo politika konusudur. cake politika nesnesidir. eat eylemdir. Tam anlamı jojo konusunun cake nesnesi üzerinde eat eylemini gerçekleştirebileceğidir. Somut politika kuralları model dosyasında görünmez. Bunun yerine özel politika dosyaları veya veritabanları kullanılarak saklanır.

İstek

Yapılandırma dosyasında istek tanımı bölümü:

[request_definition]
r = sub, obj, act

r request (istek) anlamına gelir ve başka karakterlerle değiştirilemez. sub subject (konu) istek konusudur. obj object (nesne) istek nesnesidir. act action (eylem) istek eylemidir. Genellikle istek tanımı politika tanımı ile aynı alan adlarına sahiptir. İstek bölümü casbin tarafından yönetilmez. Geliştirici neyin istek konusu neyin istek nesnesi olduğuna karar verir. Casbin yalnızca iletilen alanlara göre erişim kontrolü yapar.

Eşleştirme

Yapılandırma dosyasında eşleştirme tanımı bölümü:

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act

m matcher (eşleştirici) anlamına gelir ve başka karakterlerle değiştirilemez. Ardından ilgili eşleştirme kuralları gelir. Yukarıdaki basit bir boolean ifadesidir. İletilen isteğin tüm alanları politika kurallarının alanlarıyla tamamen eşleşiyorsa eşleşme sağlanır. Elbette bu joker karakterler veya daha güçlü ifade yeteneğine sahip regex olabilir.

Bunun dışında matcher in sözdizimini de destekler. Örneğin:

[matchers]
m = r.sub in ("root","admin")

Veya:

[matchers]
m = r.sub.Name in (r.obj.Admins)
go
e.Enforce(Sub{Name: "alice"}, Obj{Name: "a book", Admins: []interface{}{"alice", "bob"}})

Eşleştirme yapılırken Casbin tür kontrolü yapmaz. Bunun yerine interface olarak ele alır ve == ile eşit olup olmadığını kontrol eder.

Etki

Etki tanımı bölümü eşleşme sonuçları üzerinde mantıksal kombinasyon ve değerlendirme yapar. Yapılandırma dosyasında etki tanımı bölümü:

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

e effect (etki) anlamına gelir ve başka karakterlerle değiştirilemez. some nicelleyicisi eşleştiriciyi karşılayan en az bir politika kuralı olup olmadığını kontrol eder. any nicelleyicisi ise tüm politika kurallarının eşleştiriciyi karşılayıp karşılamadığını kontrol eder.

some(where (p.eft == allow))

Bu kural eşleşme sonuçlarında en az bir allow sonucu varsa final sonucunun allow olacağı anlamına gelir.

e = !some(where (p.eft == deny))

Bu kural eşleşme sonuçlarında deny sonucu yoksa final sonucunun allow olacağı anlamına gelir.

e = some(where (p.eft == allow)) && !some(where (p.eft == deny))

Bu kural eşleşme sonuçlarında en az bir allow sonucu varsa ve deny sonucu yoksa final sonucunun allow olacağı anlamına gelir.

Casbin bu politika etkisi sözdizimini tasarlamış olsa da mevcut uygulama sabit kodlanmış politika etkilerini kullanır. Bu esnekliğin çok gerekli olmadığını düşünüyorlar. Şu anda dahili politika etkilerini kullanmanız gerekiyor. Özel politika etkileri oluşturamazsınız. Dahili olarak desteklenen politika etkileri aşağıdaki gibidir:

Politika Etkisi TanımıAnlamıÖrnek
some(where (p.eft == allow))allow-overrideACL, RBAC, vb.
!some(where (p.eft == deny))deny-overrideReddetme Yeniden Yazma
some(where (p.eft == allow)) && !some(where (p.eft == deny))allow-and-denyİzin ve Reddetme
priority(p.eft) || denypriorityÖncelik
subjectPriority(p.eft)Rol Tabanlı ÖncelikKonu Önceliği

TIP

  1. Yukarıdaki dört tanımın birden fazlası tanımlanabilir. Sözdizimi type+number şeklindedir. Örneğin r2, p2, e2, m2.

  2. Model dosyası yorum satırları içerebilir. # sembolü ile yorum yapılır.

Örnek

Aşağıda model dosyasının çalışma sürecini gösteren bir örnek verilmiştir. İlk olarak basit bir ACL model dosyası tanımlayalım:

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

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

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act

Politika dosyası:

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

Konu, nesne ve eylemin nasıl soyutlanacağı iş mantığına bağlıdır. Burada önemli olmadığı için atlanmıştır. Aşağıda en basit şekilde iletilen istek gösterilmiştir:

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

Politika dosyasında alice'in data1 üzerinde read işlemi yapma yetkisi bob'un data2 üzerinde write işlemi yapma yetkisi tanımlanmıştır. İletilen isteklerde:

alice, data1, read

alice'in data1 üzerinde read işlemi yapmak istediğini gösterir.

bob, data1, read

bob'un data1 üzerinde read işlemi yapmak istediğini gösterir. Diğerleri de benzer şekildedir. Final sonuç:

true
false
false
true

Bu en basit ACL örneğidir. Casbin resmi web sitesinde online düzenleme ve test yapabilirsiniz. Casbin editor adresinden test edebilirsiniz.

RBAC

RBAC (Role-Based Access Control - Rol Tabanlı Erişim Kontrolü), ACL modeline kıyasla ek bir [role_definition] bölümüne sahiptir. Aşağıda basit bir RBAC modeli verilmiştir:

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[role_definition]
g = _, _

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

[matchers]
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act

Rol tanımı:

[role_definition]
g = _, _

g group (grup) anlamına gelir ve başka karakterlerle değiştirilemez. type+number şeklinde birden fazla oluşturulabilir. _ yer tutucudur ve kaç parametre olduğunu gösterir. Genellikle Policy'de g şu formattadır:

g, alice, data2_admin
g, mike, data1_admin
g, data1_admin data2_admin

alice konuyu data2_admin rolü ifade eder. Kesin olarak casbin bunları string olarak görür. Nasıl yorumlanacağı ve kullanılacağı geliştiriciye bağlıdır.

g, alice, data2_admin

alice'in data2_admin rolüne sahip olduğunu gösterir.

g, mike, data1_admin

mike'ın data1_admin rolüne sahip olduğunu gösterir.

g, data1_admin data2_admin

data1_admin rolünün data2_admin rolüne sahip olduğunu gösterir. Bu roller arasındaki kalıtım ilişkisidir.

Kaynak Rol Modeli

Kaynak rol modeli kaynak rol tanımı için ek bir g2 ekler. Model tanımı:

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

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

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

[matchers]
m = g(r.sub, p.sub) && g2(r.obj, p.obj) && r.act == p.act

Policy örneği:

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

g, alice, data_group_admin
g2, data1, data_group
g2, data2, data_group

g2 kaynak rol grubunu tanımlar. Kaynakları farklı rollere atar ve kullanıcı rolleri ile kaynak rolleri arasındaki kullanıcı ilişkilerini düzenler.

p, data_group_admin, data_group, write

Bu politika kuralı data_group_admin rolüne sahip kullanıcının data_group rolüne sahip kaynak üzerinde write işlemi yapabileceğini tanımlar.

Çok Kiracılı Domain Modeli

[request_definition]
r = sub, dom, obj, act

[policy_definition]
p = sub, dom, obj, act

[role_definition]
g = _, _, _

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

[matchers]
m = g(r.sub, p.sub, r.dom) && r.dom == p.dom && r.obj == p.obj && r.act == p.act

Çok kiracılı domain modeli geleneksel RBAC modeline ek olarak dom alanına sahiptir. Konunun ait olduğu domain'i göstermek için kullanılır. Policy örneği:

p, admin, domain1, data1, read
p, admin, domain1, data1, write
p, admin, domain2, data2, read
p, admin, domain2, data2, write

g, alice, admin, domain1
g, bob, admin, domain2

Örneğin:

p, admin, domain1, data1, read

domain1 domain'ine ait admin konusunun data1 üzerinde read işlemi yapma yetkisi olduğunu tanımlar.

g, alice, admin, domain1

alice'in domain1'e ait olduğunu ve admin rolüne sahip olduğunu tanımlar.

ABAC

Golang by www.golangdev.cn edit