Menu Permissions

Wir beginnen mit der Vorstellung eines Spring Boot-Beispiels mit einem Menüsystem. Dieses Beispiel nutzt jCasbin zur Verwaltung von Menüberechtigungen. Letztendlich zielt es darauf ab, eine Middleware zu abstrahieren, speziell für Menüberechtigungen, die auf andere von Casbin unterstützte Sprachen, wie Go und Python, erweitert werden könnte.

1. Konfigurationsdateien

Sie müssen die Rollen- und Berechtigungsverwaltung in der policy.csv-Datei einrichten, zusammen mit den Eltern-Kind-Beziehungen zwischen Menüpunkten. Für weitere Details verweisen Sie bitte auf dieses GitHub-Repo.

1.1 Übersicht

Mit policy.csv können Sie flexibel Rollenberechtigungen und Menüstrukturen für feinkörnige Zugriffskontrolle konfigurieren. Diese Konfigurationsdatei definiert Zugriffsberechtigungen für verschiedene Rollen auf verschiedene Menüpunkte, Verbindungen zwischen Benutzern und Rollen und die hierarchischen Beziehungen zwischen Menüpunkten.

1.2 Berechtigungsdefinitionen (Richtlinien)

• Richtlinienregeln: Richtlinien werden mit einem p-Präfix definiert, das Rollen (sub) und ihre Berechtigungen (act) auf Menüpunkten (obj) angibt, zusammen mit der Wirkung der Regel (eft), wobei allow die Gewährung der Berechtigung anzeigt und deny ihre Ablehnung.

Beispiele:

• p, ROLE_ROOT, SystemMenu, read, allow bedeutet, dass die Rolle ROLE_ROOT Lesezugriff auf den Menüpunkt SystemMenu hat.
• p, ROLE_ROOT, UserMenu, read, deny bedeutet, dass der Rolle ROLE_ROOT der Lesezugriff auf den Menüpunkt UserMenu verweigert wird.

1.3 Rollen und Benutzerzuordnungen

• Rollenvererbung: Benutzer-Rollen-Beziehungen und Rollenhierarchien werden mit einem g-Präfix definiert. Dies ermöglicht es Benutzern, Berechtigungen von einer oder mehreren Rollen zu erben.

Beispiele:

• g, user, ROLE_USER bedeutet, dass dem Benutzer user die Rolle ROLE_USER zugewiesen wird.
• g, ROLE_ADMIN, ROLE_USER bedeutet, dass ROLE_ADMIN Berechtigungen von ROLE_USER erbt.

1.4 Hierarchie der Menüpunkte

• Menübeziehungen: Eltern-Kind-Beziehungen zwischen Menüpunkten werden mit einem g2-Präfix definiert, um beim Aufbau der Menüstruktur zu helfen.

Beispiele:

• g2, UserSubMenu_allow, UserMenu zeigt an, dass UserSubMenu_allow ein Untermenü von UserMenu ist.
• g2, (NULL), SystemMenu zeigt an, dass SystemMenu keinen Untermenüpunkt hat, was bedeutet, dass es sich um einen obersten Menüpunkt handelt.

1.5 Vererbung von Menüberechtigungen und Standardregeln

Bei der Verwaltung von Menüberechtigungen mit jCasbin folgt die Berechtigungsbeziehung zwischen Eltern- und Kindermenüs spezifischen Vererbungsregeln, mit zwei wichtigen Standardregeln:

Vererbung von Elternmenüberechtigungen:

Wenn einem übergeordneten Menü explizit die allow Berechtigung erteilt wird, haben alle seine Untermenüs standardmäßig auch die allow Berechtigung, es sei denn, sie sind speziell als deny gekennzeichnet. Das bedeutet, dass sobald ein übergeordnetes Menü zugänglich ist, auch seine Untermenüs standardmäßig zugänglich sind.

Behandlung von übergeordneten Menüs ohne direkte Berechtigungseinstellungen:

Wenn ein übergeordnetes Menü keine direkten Berechtigungseinstellungen hat (weder explizit erlaubt noch verweigert), aber mindestens ein Untermenü explizit die allow Berechtigung hat, dann wird das übergeordnete Menü implizit als allow Berechtigung betrachtet. Dies stellt sicher, dass Benutzer zu diesen Untermenüs navigieren können.

1.6 Spezielle Regeln zur Berechtigungsvererbung

Bezüglich der Vererbung von Berechtigungen zwischen Rollen, insbesondere in Szenarien mit deny Berechtigungen, müssen die folgenden Regeln eingehalten werden, um die Systemsicherheit und die präzise Kontrolle von Berechtigungen zu gewährleisten:

Unterscheidung zwischen expliziten und standardmäßigen Verweigerungen:

Wenn einer Rolle, wie ROLE_ADMIN, explizit der Zugriff auf einen Menüpunkt, wie AdminSubMenu_deny (als deny gekennzeichnet), verweigert wird, dann ist selbst wenn diese Rolle von einer anderen Rolle (z.B. ROLE_ROOT) geerbt wird, der ererbenden Rolle der Zugriff auf den verweigerten Menüpunkt nicht gestattet. Dies stellt sicher, dass explizite Sicherheitsrichtlinien nicht aufgrund von Rollenvererbung umgangen werden.

Vererbung von standardmäßigen Verweigerungsberechtigungen:

Umgekehrt, wenn die Verweigerung einer Rolle des Zugriffs auf einen Menüpunkt (z.B. UserSubMenu_deny) standardmäßig ist (nicht explizit als deny gekennzeichnet, sondern weil sie nicht explizit allow gewährt wurde), dann kann, wenn diese Rolle von einer anderen Rolle (z.B. ROLE_ADMIN) geerbt wird, die ererbende Rolle den standardmäßigen deny Status überschreiben und den Zugriff auf diese Menüpunkte erlauben.

1.7 Beispielbeschreibung

Richtlinie:

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üName	ROLE_ROOT	ROLE_ADMIN	ROLE_USER
SystemMenu	✅	❌	❌
UserMenu	❌	✅	❌
UserSubMenu_allow	❌	✅	✅
UserSubSubMenu	❌	✅	✅
UserSubMenu_deny	❌	✅	❌
AdminMenu	✅	✅	❌
AdminSubMenu_allow	✅	✅	❌
AdminSubMenu_deny	✅	❌	❌

2. Menüberechtigungskontrolle

Die Liste aller Menüpunkte, auf die ein bestimmter Benutzername Zugriff hat, kann über die Funktion findAccessibleMenus() identifiziert werden, die im MenuService verfügbar ist. Um zu überprüfen, ob ein bestimmter Benutzer die Rechte hat, auf einen bestimmten Menüpunkt zuzugreifen, kann die Methode checkMenuAccess() verwendet werden. Dieser Ansatz stellt sicher, dass Menüberechtigungen effektiv kontrolliert werden und nutzt die Fähigkeiten von jCasbin zur effizienten Verwaltung von Zugriffsrechten.