© Excellent backgrounds/Shutterstock.com
Java Magazin
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.

Daniel Brenner, Stefan Zilch


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.

Abb. 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 e...

Java Magazin
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.

Daniel Brenner, Stefan Zilch


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.

Abb. 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 e...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang