"Devilish" ACL - meine Option zum Überprüfen von Rechten

    Ich mache mein CMS (genauer gesagt, was ich CMS nenne). Das Projekt hat die Stufe der Überprüfung der Benutzerrechte erreicht. Ein solches System sollte Folgendes ermöglichen:

    1. Überprüfen Sie die Ressourcenbenutzerrechte
    2. Weisen Sie einer Gruppe Ressourcenrechte zu
    3. Vererben von Rechten von einem Elternteil an eine untergeordnete Gruppe
    4. Regeln für übergeordnete Ressourcen gelten für alle untergeordneten Ressourcen
    5. Vererbung von Rechten (Beispiel: Das Recht auf Änderung schließt das Recht auf Lesen ein)

    Ich werde versuchen, meine Vision eines solchen Rechtssystems zu beschreiben.


    Berechtigungen


    Zunächst eine kleine Terminologie, an die ich mich halten werde. Die Erlaubnis ist eine bestimmte Aktion. Das Recht ist die Fähigkeit des Benutzers, eine Aktion auszuführen.
    Standardmäßig verfügt das System über die folgende vordefinierte Liste von Berechtigungen.
    VornameBeschreibung
    keineKeine Rechte
    lesenLesen
    schaffenSchöpfung
    aktualisierenÄndern Sie
    löschenLöschen
    alleAlle Rechte
    Die Berechtigungen in der Liste werden vom kleinsten bis zum größten angegeben (d. H. Jede nachfolgende Berechtigung (Zeile) enthält alle vorherigen Berechtigungen). Wenn einem Benutzer beispielsweise das Recht zum Erstellen zugewiesen wurde , hat er auch das Recht zum Lesen . Dementsprechend gibt die Erlaubnis alle - alle Rechte. Und Erlaubnis keine ist ein Verbot aller Rechte.

    Ressourcen


    Die Ressource wird als Link / aaa / bbb / ccc / festgelegt . Darüber hinaus gelten alle Rechte, die beispielsweise für / aaa / festgelegt wurden , für alle untergeordneten Ressourcen: / aaa / bbb / , / aaa / bbb / ccc / usw. Für die Ressource / aaa / bbb / resource / aaa / is parent ist resource / aaa / bbb / ccc / is child.

    Gruppen



    Eine Gruppe ist ein Objekt, in dem die Zuweisung von Rechten (Zuweisung von Regeln) zu Ressourcen erfolgt. Für alle Gruppen gibt es EINE übergeordnete Gruppe. Diese Gruppe hat alle Rechte an allen Ressourcen. Normalerweise nennt man eine solche Gruppe Superadmin, Gott (god). Aber um mich von anderen ACLs zu unterscheiden, habe ich eine solche Stammgruppe als diablo (Teufel) bezeichnet. Also werden in meinem System alle Rechte "vom Teufel" sein. Daher der Titel des Artikels über die teuflische Acl .
    Jede Untergruppe kann nur die Rechte VERRINGERN. Das heißt Wenn die Administratorgruppe (Administrator) das Erstellungsrecht für die Ressource / aaa / bbb / ccc / hat, kann die Benutzergruppe (Benutzer) das Recht zum Löschen der Ressource aaa / bbb / ccc / nicht erhalten. In diesem Fall erhöht sich das Recht wie die Löschberechtigung höher ist als die Erstellungsberechtigung. Außerdem kann die Benutzergruppe das Löschrecht für die Ressourcen / aaa / bbb /, / aaa /, / nicht erhalten, da dies die übergeordneten Ressourcen für die Ressource / aaa / bbb / ccc / sind, was in diesem Fall bedeutet, dass sich auch die Rechte erhöhen . Das Prinzip der Rechteverringerung ist erforderlich, damit Benutzer Gruppen leiten können und keine Angst haben, auf Ressourcen zuzugreifen, die Sie ihnen nicht anzeigen möchten, da sie sich keine Rechte hinzufügen können, die sie nicht haben.
    Jede Gruppe kann nur eine Regel für eine Ressource enthalten (einschließlich übergeordneter Ressourcen). Wenn beispielsweise eine Regel für die Ressource / aaa / bbb / ccc / in der Gruppe festgelegt ist, sollten keine anderen Regeln für die Ressourcen / aaa / bbb / ccc /, / aaa / bbb /, / aaa /, / vorhanden sein.

    Tabellen


    Tabellen zur Datenspeicherung.


    Überprüfungsfunktion: Hat der Benutzer die Berechtigung für die Ressource


    Als Beispiel überprüfen wir die Erstellungsberechtigung des Benutzers für die Ressource /aaa/bbb/ccc/index.html.
    Zuerst ein Bild des Gruppenbaums, auf dem ich Beispiele für ein besseres Verständnis des Algorithmus (einschließlich meiner selbst) beschreibe. Gruppe Nr. 1 ist die Diablo-Gruppe, die alle Rechte auf alles hat. In den Gruppen 12, 13, 15, 10 werden Regeln für die Ressource festgelegt, die wir für Berechtigungen <benötigen. Dies führt zu einem Verbot der Ressource. In den Gruppen 3, 4, 22 werden Regeln für die Ressource festgelegt, die wir für Berechtigungen benötigen, die ≥ gegeben sind - was die Zugriffsebene verringert, aber dennoch unter unser Beispiel fällt. Das heißt Wenn in Gruppe 1 die Ressourcenberechtigung auf alle festgelegt ist, wird in Gruppe 3 die Berechtigung zum Löschen festgelegt, die immer noch höher ist als die im Beispiel festgelegte Berechtigung zum Erstellen.

    Der Operationsalgorithmus ist wie folgt:
    1. Gemäß der Users- Tabelle identifizieren wir die Liste der Gruppen ( aGroupsUsers ), zu denen dieser Benutzer gehört, anhand der Benutzer- ID (und der ID = 0 - Gast-ID) . In unserem Beispiel ist dies eine Liste der folgenden Gruppen.

      Wie Sie in unserem Beispiel sehen können, ist der Benutzer in Gruppe 2 und in den untergeordneten Gruppen 23 und 13 definiert. Theoretisch ist die Anwesenheit des Benutzers in den Gruppen 23 und 13 redundant, da sie für ALLE untergeordneten Gruppen gilt, wenn der Benutzer in der übergeordneten Gruppe definiert ist. In der Praxis ist dies jedoch möglich (schon deshalb, weil es einen Benutzer mit der Kennung 0 (Gast) gibt, zu dem jeder berechtigte Benutzer gehört). Deshalb habe ich ein solches Beispiel gemacht.
    2. Gemäß der Berechtigungstabelle definieren wir eine Liste von zwei Gruppen von Berechtigungskennungen: a) welche <angegeben b) welche ≥ angegeben. Um beispielsweise das Erstellen zu ermöglichen, werden die folgenden Listen erstellt: a) aDeny = [keine, lesen, aktualisieren] b) aAllow = [erstellen, löschen, alle].
    3. Wir unterteilen die Ressource in Komponenten: d.h. Zusätzlich zur Ressource selbst bestimmen wir alle Eltern. Für die Ressource /aaa/bbb/ccc/index.html erhalten wir beispielsweise die folgende Liste: /aaa/bbb/ccc/index.html, / aaa / bbb / ccc /, / aaa / bbb /, / aaa /, /. Aus der Ressourcen- Tabelle ermitteln wir die Kennungen der angegebenen Ressourcenliste ( aResources ).
    4. Gemäß der Regeltabelle und der Liste der Bezeichner aus Absatz 3 wählen wir die Liste der Gruppen ( aGroupsRules ) aus, in denen die Regeln für die angegebene Ressource definiert sind (+ übergeordnete Ressourcen). In unserem Fall lautet das Ergebnis wie folgt:

      In der Praxis gibt es möglicherweise Regeln, die in den untergeordneten Gruppen angegeben sind, zu denen der Benutzer gehört. Und sie fallen in die Probe. In unserem Beispiel gehen wir jedoch davon aus, dass es keine solchen Gruppen gibt - sie haben jedoch keinen Einfluss auf das Ergebnis.
    5. Wir haben eine Liste von Gruppen ausgewählt, zu denen der Benutzer gehört (siehe Absatz 1). Jetzt müssen wir alle diese Gruppen auf die erforderlichen Rechte für die von uns festgelegte Ressource überprüfen, wobei die Rechte der Eltern berücksichtigt werden. Das heißt Wir müssen die folgenden Gruppenzweige überprüfen (der Gruppenzweig ist eine Liste von Gruppen von der aktuellen bis zur Wurzel (dem Teufel)):
      • 23, 12, 6, 2, 1
      • 13, 6, 2, 1
      • 2, 1
      • 38, 27, 17, 8, 3, 1
      • 18 ,, 9, 4, 1
      • 20, 10, 4, 1
      • 32, 22, 11, 5, 1
      Wenn außerdem in einer der Niederlassungen das Ergebnis der Überprüfung der Rechte positiv ist, ist es nicht erforderlich, den Rest zu überprüfen, da wir bereits Rechte haben. Wenn wir während der Suche zu der Gruppe gewechselt sind, in der die Verbotsregel festgelegt wurde, können Sie diesen Zweig deaktivieren und mit dem nächsten fortfahren. Das Folgende ist ein Algorithmus zum Bestimmen von Rechten. Am Ende des Algorithmus enthält die Variable fAccessGroup das Ergebnis des Benutzerzugriffs auf die Ressource: Wahr / Falsch.

      In unserem Beispiel endet die Suche im Zweig "2, 1", da er Zugriff auf die Ressource hat.
      Ich möchte Sie auch auf die Tatsache aufmerksam machen, dass Sie gemäß diesem Algorithmus die Zugriffsrechte des Teufels in keiner Weise ändern können - er hat immer Rechte auf alles, nur aufgrund seines Namens diablo.

    Optimierung
    Wie Sie sehen (wenn Sie den Algorithmus der Arbeit lesen), erhalten wir viele Stichproben aus der Datenbank, da wir beim Überprüfen des Zweigs einer Gruppe nacheinander von der untergeordneten Gruppe zur übergeordneten Gruppe wechseln und je länger der Zweig ist, desto mehr Stichproben aus der Datenbank müssen Sie ausführen. Eine Möglichkeit, die Arbeitsgeschwindigkeit zu erhöhen, besteht darin, die Suchergebnisse gruppenweise zwischenzuspeichern. Das heißt Wenn wir bei der nächsten Prüfung festgestellt haben, dass die Gruppe G die Berechtigung P für die Ressource R hat , können wir diese in einer separaten Tabelle speichern

    In diesem Fall können wir nach Schritt 3 Daten aus der Cache-Tabelle aus der Liste der aGroupsUsers-Gruppen und der Liste der aResources-Ressourcen auswählen. Wenn für die ausgewählten Daten Berechtigungen ≥ erforderlich sind, hat der Benutzer Zugriff auf die Ressource. Wenn nicht, dann führen wir Prüfungen nach dem beschriebenen Algorithmus durch. Bei der Überprüfung des Gruppenzweigs berücksichtigen wir die Informationen über das vom CACHE ausgewählte Verbot.
    Ich werde diesen Prozess nicht im Detail beschreiben, da dies bereits auf eine bestimmte Implementierung hinweist und ich in dem Artikel eine allgemeine Beschreibung des Operationsalgorithmus vornehmen wollte. Wenn Sie jedoch Optimierungsvorschläge haben, schreiben Sie diese in die Kommentare.


    Einige Notizen


    • Rein theoretisch wird die Berechtigungstabelle nicht besonders benötigt, da Sie Berechtigungen in einem regulären Array speichern können (genau das habe ich vor). Anstelle von Berechtigungskennungen können Sie den technischen Namen (keine, lesen, erstellen, aktualisieren, löschen usw.) der Berechtigung in die Regeltabelle schreiben. Ich habe jedoch immer noch auf eine solche Tabelle hingewiesen, da es für jemanden möglicherweise einfacher ist, Berechtigungen in der Tabelle zu speichern, und es außerdem möglicherweise klarer ist.
    • Standardmäßig muss der Benutzer mit der ID 0 (Gast) in der Gastgruppe enthalten sein. Alle neuen Benutzer sollten in die Benutzergruppe aufgenommen werden.
    • Jedes Modul fügt Regeln für seine Ressourcen hinzu (obwohl dies wahrscheinlich bereits für den jeweiligen Implementierungsfall gilt und nicht für die Zugriffskontrolle gilt).
    • Für diejenigen, die einen Kommentar im Stil von "Was zum Teufel haben Sie gedacht, weil es [fast] genau im XXX-System implementiert ist" schreiben möchten: Die Implementierung im XXX-System ist für mich nicht geeignet, da ich ein selbstgeschriebenes System (bis auf ein selbstgeschriebenes ORM) habe und implementiere Überprüfung der Rechte werde ich darauf sein. Verweise auf Systeme, in denen das Rechtesystem [fast] implementiert ist, sind daher ebenfalls willkommen, ohne jedoch darauf hinzuweisen, dass ich dieses System nicht vergeblich verschraubt habe.
    • Wenn jemand ein Problem gefunden hat, das ich übersehen habe - schreibe es in die Kommentare. Dies ist die dritte Version des Artikels, die beiden vorherigen wurden abgelehnt, da beim Schreiben des Artikels Fehler im Algorithmus festgestellt wurden
    • Ich habe die Option in Betracht gezogen, wenn der Teufel keine Rechte an irgendetwas hat und die Rechte zunehmen. In diesem Fall ist die Wahrscheinlichkeit geringer, dass jemandem Zugriff auf verbotene Inhalte gewährt wird. Wenn Sie dem Benutzer bei diesem Ansatz jedoch das Recht geben, Gruppen Rechte zuzuweisen, kann er sich selbst den vollständigen Zugriff zuweisen. Am Ende entschied ich, dass der Teufel allmächtig sein würde .

    Liste verwandter Links:


    ps Wenn Sie Nachteile setzen, dann schreiben Sie zumindest - wofür .

    Jetzt auch beliebt: