Ana içeriğe atla

Menu Permissions

Bir menü sistemi özellikli bir Spring Boot örneğiyle başlıyoruz. Bu örnek, menü izinlerini yönetmek için jCasbin'i kullanır. Sonunda, özellikle menü izinleri için soyut bir ara katman hedefler, bu da Casbin tarafından desteklenen diğer dillere, örneğin Go ve Python'a genişletilebilir.

1. Yapılandırma Dosyaları​

policy.csv dosyasında rol ve izin yönetimini kurmanız, ayrıca menü öğeleri arasındaki ana-çocuk ilişkileriyle birlikte yapmanız gerekmektedir. Daha fazla ayrıntı için lütfen bu GitHub deposuna başvurun.

1.1 Genel Bakış​

policy.csv kullanarak, ayrıntılı erişim kontrolü için rol izinlerini ve menü yapılarını esnek bir şekilde yapılandırabilirsiniz. Bu yapılandırma dosyası, farklı menü öğelerinde çeşitli roller için erişim izinlerini, kullanıcılar ve roller arasındaki ilişkileri ve menü öğeleri arasındaki hiyerarşik ilişkileri tanımlar.

1.2 İzin Tanımları (Politikalar)​

  • Politika Kuralları: Politikalar, p öneki ile tanımlanır ve roller (sub), menü öğelerindeki (obj) izinleri (act) ve kuralın etkisi (eft) belirtilir; burada allow izin verildiğini, deny ise reddedildiğini gösterir.

Örnekler:

  • p, ROLE_ROOT, SystemMenu, read, allow ifadesi, ROLE_ROOT rolünün SystemMenu menü öğesine okuma erişimine sahip olduğu anlamına gelir.
  • p, ROLE_ROOT, UserMenu, read, deny ifadesi, ROLE_ROOT rolünün UserMenu menü öğesine okuma erişimi reddedildiği anlamına gelir.

1.3 Roller ve Kullanıcı İlişkileri​

  • Rol Kalıtımı: Kullanıcı-rol ilişkileri ve rol hiyerarşileri g öneki ile tanımlanır. Bu, kullanıcıların bir veya birden fazla rolden izinleri miras almalarına olanak tanır.

Örnekler:

  • g, user, ROLE_USER ifadesi, user kullanıcısına ROLE_USER rolünün atandığını belirtir.
  • g, ROLE_ADMIN, ROLE_USER ifadesi, ROLE_ADMIN rolünün ROLE_USER'dan izinleri miras aldığını belirtir.

1.4 Menü Öğesi Hiyerarşisi​

  • Menü İlişkileri: Menü öğeleri arasındaki ana-çocuk ilişkileri g2 öneki ile tanımlanır ve menünün yapısının oluşturulmasına yardımcı olur.

Örnekler:

  • g2, UserSubMenu_allow, UserMenu, UserSubMenu_allow'un UserMenu'nin bir alt menüsü olduğunu gösterir.
  • g2, (NULL), SystemMenu, SystemMenu'nin alt menü öğesi olmadığını, yani en üst düzey bir menü öğesi olduğunu gösterir.

1.5 Menü İzin Mirası ve Varsayılan Kurallar​

jCasbin ile menü izinlerini yönetirken, üst ve alt menüler arasındaki izin ilişkisi belirli miras kurallarına uygun olarak işler ve iki önemli varsayılan kural vardır:

Üst Menü İzinlerinin Mirası:

Eğer bir üst menü açıkça izin ver olarak belirlenmişse, tüm alt menüler de özellikle reddet olarak işaretlenmedikçe varsayılan olarak izin ver iznine sahip olurlar. Bu, bir üst menü erişilebilir olduğunda, alt menülerin de varsayılan olarak erişilebilir olduğu anlamına gelir.

Doğrudan İzin Ayarları Olmayan Üst Menülerin İşlenmesi:

Eğer bir üst menü doğrudan izin ayarlarına (açıkça izin verilmemiş veya reddedilmemiş) sahip değilse, ancak en az bir alt menü açıkça izin ver olarak belirlenmişse, o zaman üst menü örtülü olarak izin ver iznine sahip kabul edilir. Bu, kullanıcıların bu alt menülere gidebilmesini sağlar.

1.6 Özel İzin Miras Alma Kuralları​

Roller arasında izin mirası söz konusu olduğunda, özellikle deny izinleri içeren senaryolarda, sistem güvenliğini ve izinlerin kesin kontrolünü sağlamak için aşağıdaki kuralların takip edilmesi gerekir:

Açık ve Varsayılan Redler Arasındaki Ayrım:

Örneğin, ROLE_ADMIN gibi bir rol, AdminSubMenu_deny gibi bir menü öğesine açıkça erişim reddedildiyse (deny olarak işaretlendiği için), bu rolün başka bir role (ör. ROLE_ROOT) miras kaldığında, miras alan rol reddedilen menü öğesine erişim izni verilmez. Bu, açık güvenlik politikalarının rol mirası nedeniyle atlanmamasını sağlar.

Varsayılan Red İzinlerinin Mirası:

Tersine, bir role (ör. UserSubMenu_deny) bir menü öğesine erişimin reddedilmesi varsayılan ise (açıkça deny olarak işaretlenmemiş, ancak açıkça allow verilmemişse), bu rolün başka bir role (ör. ROLE_ADMIN) miras kaldığında, miras alan rol varsayılan deny durumunu geçersiz kılabilir, bu menü öğelerine erişime izin verebilir.

1.7 Örnek Açıklama​

politika:

p, ROLE_ROOT, SystemMenu, read, allow
p, ROLE_ROOT, AdminMenu, read, allow
p, ROLE_ROOT, UserMenu, read, deny
p, ROLE_ADMIN, UserMenu, read, allow
p, ROLE_ADMIN, AdminMenu, read, allow
p, ROLE_ADMIN, AdminSubMenu_deny, read, deny
p, ROLE_USER, UserSubMenu_allow, read, allow

g, user, ROLE_USER
g, admin, ROLE_ADMIN
g, root, ROLE_ROOT
g, ROLE_ADMIN, ROLE_USER

g2, UserSubMenu_allow, UserMenu
g2, UserSubMenu_deny, UserMenu
g2, UserSubSubMenu, UserSubMenu_allow
g2, AdminSubMenu_allow, AdminMenu
g2, AdminSubMenu_deny, AdminMenu
g2, (NULL), SystemMenu
MenüAdıROLE_ROOTROLE_ADMINROLE_USER
SystemMenu✅❌❌
UserMenu❌✅❌
UserSubMenu_allow❌✅✅
UserSubSubMenu❌✅✅
UserSubMenu_deny❌✅❌
AdminMenu✅✅❌
AdminSubMenu_allow✅✅❌
AdminSubMenu_deny✅❌❌

2. Menü İzin Kontrolü​

Belirli bir kullanıcı adıyla erişilebilen tüm menü öğelerinin listesi, MenuService içinde bulunan findAccessibleMenus() fonksiyonu aracılığıyla tanımlanabilir. Belirli bir kullanıcının belirlenmiş bir menü öğesine erişim hakkına sahip olup olmadığını kontrol etmek için checkMenuAccess() metodu kullanılabilir. Bu yaklaşım, menü izinlerinin etkili bir şekilde kontrol edilmesini sağlar ve jCasbin'in yeteneklerinden yararlanarak erişim haklarını verimli bir şekilde yönetir.