Wie entwerfe ich eine rollenbasierte Zugriffssteuerung?

Ich versuche, dem Zugriffssteuerungsmodell der Rollenbasis zu folgen, um einzuschränken, was Benutzer in meinem System tun können oder nicht.

Bisher habe ich folgende Entitäten:

Benutzer - Personen, die das System verwenden. Hier habe ich Benutzernamen und Passwörter. Rollen - Sammlung von Rollen, die Benutzer haben können. Dinge wie Manager, Administrator usw. Ressourcen - Dinge, die Benutzer manipulieren können. Wie Verträge, Benutzer, Vertragsentwürfe usw. Operationen - Dinge, die Benutzer mit den Ressourcen tun können. Wie erstellen, lesen, aktualisieren oder löschen.

In dem Diagramm, in dem ich eine Beziehung wie diese habe, tauchen hier meine Zweifel auf:

Operationen (0 .. *) werden für Ressourcen (0 .. *) ausgeführt, die eine von mir als Berechtigungen bezeichnete Tabelle generieren , in der die Operation und die Ressource gespeichert werden .

Die Berechtigungstabelle sieht folgendermaßen aus (eine Zeile davon): ID: 1, Vorgang: Erstellen, Ressource: Vertrag.

Das bedeutet eine Erlaubnis , einen Vertrag zu erstellen .

Ich habe es so gemacht, weil ich der Meinung bin, dass manche Ressourcen nicht alle Arten von Operationen haben. Zum Registrieren von Verträgen können Benutzer beispielsweise Dateien hochladen , aber dieser Vorgang steht für die Registrierung eines Anbieters nicht zur Verfügung .

Wenn der Administrator nun Berechtigungen für eine Rolle erteilt , verfügt er nicht über eine Ressourcenliste für jeden einzelnen im System registrierten Vorgang.

Ich denke, jede Ressource hat ihre eigene Sammlung von Operationen , die auf ihn angewendet werden können.

Ich kann klären, ob etwas nicht verständlich ist.

Ist dies der richtige Weg, um den RBAC zu implementieren?

BEARBEITEN

Was ich damit meine, ist, dass ich mit einer Berechtigungstabelle , die Operation und Ressource enthält , ZWEI zusätzliche Tabellen habe, weil ich Ressourcen mit Operationen verknüpfen möchte . Ich hätte auch gerade getan, dass Ressourcen Berechtigungen haben , in denen die Berechtigungstabelle die Berechtigungen speichern würde.

Was dann aber passiert wäre, wäre, dass einige Berechtigungen, die nicht einmal für einige Ressourcen existieren, erschienen wären, wenn der Administrator sie zuweisen würde.

Ich möchte also aus Sicht des Datenbankdesigns wissen, ob diese Tabellenberechtigung, die eine Spaltenoperation und eine andere Ressource enthält, korrekt ist. Werde ich Probleme bekommen, wenn es so bleibt?

Ihr Design scheint mir ziemlich nahe zu sein. Nur ein paar Vorschläge.

Benutzer - Personen, die das System verwenden. Hier habe ich Benutzernamen und Passwörter.

Fein

Rollen - Sammlung von Rollen, die Benutzer haben können. Sachen wie Manager, Admin usw.

Auch gut. Sie benötigen jedoch auch eine Entität / Tabelle "UserRoles", in der angegeben wird, welche Benutzer welche Rollen haben. Es ist wahrscheinlich, dass ein bestimmter Benutzer zwei oder mehr Rollen hat.

Ressourcen - Dinge, die Benutzer manipulieren können. Wie Verträge, Benutzer, Vertragsentwürfe usw.

Könnte nur eine Frage der Semantik sein. Ich glaube nicht, dass Benutzer Ressourcen direkt manipulieren. Rollen tun. So geht es Benutzer -> Benutzerrolle -> Rolle -> Operation -> Ressource

Operationen - Dinge, die Benutzer mit den Ressourcen tun können. Wie erstellen, lesen, aktualisieren oder löschen.

Ja, außer "Rollen" statt "Benutzer"

Die Berechtigungstabelle sieht folgendermaßen aus (eine Zeile davon): ID: 1, Vorgang: Erstellen, Ressource: Vertrag. Das bedeutet eine Erlaubnis, einen Vertrag zu erstellen.

Hmmm. Hierfür gibt es zwei Möglichkeiten. Sie könnten die von Ihnen beschriebene Berechtigungstabelle haben, aber Sie würden auch eine zusätzliche RolePermissionsTabelle / Entität benötigen , die Ihnen sagt, welche Rolle welche Berechtigung hat. Ich bin mir aber nicht sicher, ob das notwendig ist.

Eine einfachere Möglichkeit ist eine Berechtigungstabelle / -entität mit den folgenden Spalten / Attributen: Rollen-ID, Operations-ID, Ressourcen-ID. Auf diese Weise werden Operationen x Ressourcenkombinationen direkt einer Rolle zugewiesen und nicht in eine Berechtigung geladen, die einer Rolle zugewiesen ist. Es eliminiert eine Entität. Es ist keine separate rollenunabhängige Berechtigungstabelle erforderlich, es sei denn, Sie möchten vordefinieren, welche Berechtigungskombinationen zulässig sind und welche nicht.

Ich würde RBAC nicht verwenden oder implementieren. Stattdessen würde ich ABAC verwenden. Lassen Sie mich erklären...

• Bei RBAC oder rollenbasierter Zugriffskontrolle geht es um Benutzerverwaltung und Rollenzuweisung. In RBAC kann man sagen, dass Alice ein Manager ist. Dazu können Sie statische Berechtigungen definieren. Ein Manager kann beispielsweise Kredite genehmigen. Es gibt also einen Link von Alice zum Manager, um Loan als Berechtigung zu genehmigen. Es gibt viele Systeme, mit denen Sie dies tun können, sodass Sie keine eigenen Tabellen implementieren müssen. Sogar LDAP unterstützt begrenzte RBAC-Sätze. Das ist in Ordnung, solange Sie nur relativ wenige Rollen und Berechtigungen haben. Aber was ist, wenn Sie bestimmte Berechtigungen berücksichtigen möchten, wie dies bei Ihnen der Fall ist? Anzeigen, Löschen, Einfügen? Was ist, wenn Sie Beziehungen berücksichtigen möchten?
• Bei der ABAC- oder attributbasierten Zugriffssteuerung handelt es sich um eine richtliniengesteuerte, differenzierte Autorisierung. Mit ABAC können Sie Rollen wie in RBAC definiert verwenden und Richtlinien schreiben, z
  • Manager können Dokumente in ihrer Abteilung anzeigen
  • Mitarbeiter können ihre eigenen Dokumente bearbeiten

In Ihrer Frage haben Sie im Wesentlichen das Informationsmodell definiert. Ihre Objekte und deren Attribute, zB ein Benutzer (Name, Passwort, Abteilung ...); ein Objekt (zB ein Vertrag) und so weiter.

In ABAC würden Sie Ihren Anwendungscode / Ihre Anwendungslogik daher vollständig von der Berechtigungslogik entkoppeln, die dann mithilfe von Attributen als Richtlinien gespeichert wird. Die Berechtigungen selbst werden direkt in der Richtlinie gespeichert (siehe Beispiel oben). Die ABAC-Implementierungsarchitektur sieht wie folgt aus

Der Punkt ist, dass Sie, wenn Sie einen ABAC-Ansatz wählen, Richtlinien für ABAC schreiben (entweder in XACML oder ALFA - dafür gibt es viele Tools) und nie wieder RBAC oder Zugriffskontrolle benutzerdefiniert codieren oder implementieren müssen.