© Excellent backgrounds/Shutterstock.com
Daten in SQL-Datenbank und ACL in Neo4j - funktioniert das?

Knoten und Kanten


Besonders im Unternehmensumfeld ist in vielen Fällen eine einfache Authentifizierung beim Zugriff auf sensible Daten nicht ausreichend, weshalb zusätzlich eine Autorisierung erforderlich wird. Diese stellt u. a. sicher, dass der Benutzer innerhalb des Systems nur dann Daten sieht oder bearbeiten kann, wenn er die notwendigen Rechte besitzt. Die Abbildung von komplexen Rechtestrukturen, Benutzergruppen, Rollen und vererbbaren Rechten ist dabei keine triviale Aufgabe. Lesen Sie, wie ein passender Lösungsansatz mit der Graphdatenbank Neo4j aussieht.

Denken Entwickler über ein Rechtesystem nach, fällt ihnen vermutlich erst einmal der Klassiker ein: die typischen CRUD-Rechte (Create, Read, Update und Delete), die in Anwendungen immer wieder modelliert und umgesetzt werden müssen. Wie auch im folgenden Beispiel: In einer Abteilung eines Versicherungsunternehmens wird die Bearbeitung von Schadensfällen aufgeteilt: Team 1 bearbeitet die Schadensfälle von A bis L und Team 2 die Fälle von M bis Z. Beide Teams können neue Schadensfälle anlegen sowie bestehende in ihrem Bereich bearbeiten und löschen. Damit die Sacharbeiter alle Schadensfälle vergleichen können, kann auf jeden Schadensfall lesend zugegriffen werden. Basierend darauf lassen sich folgende Regeln ableiten:

  • Es gibt drei Benutzergruppen „Abteilung“, „Team 1“ und „Team 2“.

  • Die Benutzergruppen „Team 1“ und „Team 2“ gehören zur Benutzergruppe „Abteilung“.

  • Alle Mitglieder der Benutzergruppe „Team 1“ dürfen Schadensfälle von A bis L aktualisieren (Update).

  • Alle Mitglieder der Benutzergruppe „Team 1“ dürfen Schadensfälle von A bis L löschen (Delete).

  • Alle Mitglieder der Benutzergruppe „Team 2“ dürfen Schadensfälle von M bis Z aktualisieren (Update).

  • Alle Mitglieder der Benutzergruppe „Team 2“ dürfen Schadensfälle von M bis Z löschen (Delete).

  • Alle Mitglieder der Benutzergruppe „Abteilung“ dürfen alle Schadensfälle lesen (Read).

  • Alle Mitglieder der Benutzergruppe „Abteilung“ dürfen neue Schadensfälle anlegen (Create).

Die Liste der Regeln demonstriert, dass solch einfaches Beispiel relativ schnell sehr komplex werden kann. Daher zeigt Abbildung 1 den Zusammenhang in grafischer Form.

brenner_neo4j_1.tif_fmt1.jpgAbb. 1: Visualisierte Rechtestruktur des Beispiels

Knoten sind die Benutzer („B1…B7“ bzw. „B2…B8“) und Benutzergruppen („Team 1“, „Team 2“ und „Abteilung“) sowie die Schadensfälle von A bis Z. Die (gerichteten) Kanten zwischen den einzelnen Knoten bilden unterschiedliche Beziehungen ab, wobei die Beschriftung die Relationsart der beiden Knoten darstellt. So markiert zum Beispiel die Kante zwischen zwei Benutzergruppen die Beziehung „Mitglied“. Benutzergruppe „Team 1“ (analog „Team 2“) ist Mitglied in der Benutzergruppe „Abteilung“. Vom Knoten „Team 1“ geht eine weitere Beziehung zum Knoten „Schadensfall A“, der die Rechte „Update“ und „Delete“ abbildet. Damit ist festgelegt, welche Rechte die Benutzergruppe, d. h. deren Mitglieder, auf Schadensfall A hat.

Beim Knoten „Schadensfall“ handelt es sich um den Datentyp, der als eigener Knoten abgebildet wird. Dieser wird eingeführt, um auf einer Metaebene Rechte vergeben zu können und somit das Rechtesystem zu vereinfachen. Die Beziehung zwischen den Knoten „Abteilung“ und „Schadensfall“ bildet dabei die Rechte „Create“ und „Read“ ab. Das bedeutet, dass alle Mitglieder der Benutzergruppe „Abteilung“ neue Objekte vom Typ „Schadensfall“ anlegen (Create) und alle Objekte vom Typ „Schadensfall“ lesen (Read) dürfen. Eine Vergabe des Rechts „Create“ auf Objektebene ist wenig sinnvoll, da dieses Objekt bereits angelegt wurde und nicht noch einmal angelegt werden kann. Im Fall des Rechts „Read“ ist es eine Vereinfachung, damit alle Mitglieder der Benutzergruppe „Abteilung“ alle Objekte vom Typ „Schadensfall“ lesen dürfen. Ist eine solche generelle Vergabe von Rechten nicht gewünscht, dann kann es zum Beispiel eine Beziehung von der Benutzergruppe „Team 1“ zu „Schadensfall“ geben, die das Recht „Read“ abbildet.

Es wäre sogar eine noch feinere Eingrenzung möglich, indem man das Leserecht zwischen einzelnen Benutzern und Schadensfällen über Kanten abbildet. In der Praxis sollte die Anforderung für solche feingranularen Fälle unbedingt gegeben sein, da dadurch Komplexität und Wartbarkeit bedeutend ansteigen.

Direkte und indirekte Benutzergruppen auffinden

Wie funktioniert nun das Rechtesystem, wenn ein Benutzer einen Schadensfall aktualisieren möchte? Dazu werden natürlich der Benutzername und die ID des Schadensfalls benötigt, die folgendermaßen ermittelt werden: Ein Benutzer kann in mehreren Benutzergruppen Mitglied sein. Weiterhin ist die Verschachtelung von Benutzergruppen möglich, was dazu führt, dass ein Benutzer auch indirekt zu einer Benutzergruppe gehören kann. Das ist wichtig, da Rechte auc...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang