Benutzerrollen und Rechteverwaltung in Webprojekten

Worum geht’s?

Wenn eure Webanwendung den Zugang einiger Bereiche beschränken soll, wird schnell eine Authentisierung von Benutzern notwendig. Nehmen wir an, dass die Registrierung und Anmeldung von Benutzern bereits vorliegt. Ein Benutzer kann sich mit seiner Kennung, bestehend aus Benutzernamen und Passwort, authentisieren. Nach aktuellem Stand können wir Benutzer zwar unterscheiden, ihnen aber keine unterschiedlichen Rollen zuweisen. Jedoch bedeutet das im Umkehrschluss, dass alle Benutzer die gleichen Rechte haben. In vielen Fällen ist dieser Umstand nachteilig.

Besserer Einblick

Ein Nachteil kann beispielhaft an einer Foren-Software erklärt werden. Ein Besucher des Forums kann die Beiträge öffentlicher Themen lesen. Nun möchte er gerne an der Diskussion teilnehmen und auf ein Thema antworten. Weil dieser Bereich der Anwendung nur für Benutzer ausgelegt ist, soll er sich registrieren und anmelden. Wenn er eingeloggt ist, kann er zudem seinen Beitrag bearbeiten oder wieder löschen. Das sind die Funktionen, die jeder Benutzer hat. Es gibt jedoch Beschränkungen: Ein User darf selbstverständlich nicht den Beitrag von jemand anderen bearbeiten. Nun ist es aber ein Anliegen des Forum-Betreibers, unpassende Beiträge zu entfernen, weil er für deren Inhalt haftet. Um dieser Aufgabe nachzukommen hat jedes Forum Administratoren und Moderatoren. Das sind ebenfalls Benutzer, aber ausgestattet mit besonderen Rechten. Dabei gilt Folgendes: Alles was ein Benutzer darf, darf auch ein Moderator und alles was ein Moderator darf, darf auch ein Administrator. Umgekehrt gilt jedoch: Ein Benutzer darf nicht, was ein Moderator oder Admin darf und ein Moderator darf nicht, was ein Admin darf.

Access Control List (ACL)

Was resultiert aus dem Beispiel? Wenn eine Softwareanwendung komplexer wird, werden Benutzerrollen und eine Rechteverwaltung notwendig. Generalisieren wir unser obiges Beispiel, entsprechen User, Administratoren und Moderatoren Benutzergruppen oder Rollen. Konkrete User können dann einer Rolle zugeordnet werden. Das Konzept von Rollen ist pyramidenförmig: Höhere Rollen setzen auf untere Rollen auf, sodass ein Administrator hochwertiger ist, als ein Moderator. Weiterhin erhält jede Rolle verschiedene Rechte oder Privilegien. Schlussendlich findet eine Dreiecksbeziehung statt. Dieses Konzept findet in der Softwareentwicklung großen Anklang und heißt „Access Control List“ (auf Deutsch: „Zugangskontrollliste“).

Umsetzung. Was ist zu beachten?

Bevor eine ACL für eine Anwendung implementiert werden kann, kommt an erster Stelle das Konzept. Es gilt zu klären für welche Bereiche der Anwendung der Zugang beschränkt werden soll und andersrum welchen Benutzergruppen der Zugang gewährt wird.

Komplexität: dynamisch oder statisch?

In nächsten Schritt bestimmen der Entwickler und die Anforderungen an die Komponente wie komplex die Umsetzung wird. Hier gibt es zwei Möglichkeiten: die Rechte und oder Rollen ändern sich dynamisch oder bleiben fest bestehen (statisch). Die Dynamik hat Auswirkungen auf das Datenbank-Design. Hinter jeder Webanwendung mit einer Zugangskontrolle steckt eine relationale Datenbank, die User speichert. Durch die Dynamik müssen zusätzlich die betroffenen Entitäten Rechte (Privileg) und Rolle persistiert werden.

Softwarearchitektur und Zeitpunkt

Danach folgt die Betrachtung der vorliegenden Softwarearchitektur. An welche Stelle gehört die Zugangsprüfung und wie wird sie eingebunden? Webanwendungen beruhen auf dem Client-Server-Pattern. Ein Client schickt Anfragen an den Server, sogenannte Requests. Als Reaktion darauf folgt eine Antwort, der sogenannte Response, vom Server. Im typischen Anwendungsfall besteht eine Webanwendung aus mehreren Webseiten. Wenn ein Benutzer nun eine dieser Seiten aufrufen möchte, dann übernimmt er indirekt die Rolle des Clients und fordert die Seite vom Server an. Der Prozess ist erst beendet, wenn die Seite auf dem Bildschirm des Anwenders vollständig aufgebaut ist.

Vor dem Seitenaufbau

Zugangsberechtigungen sind stets vor dem Seitenaufbau zu überprüfen. Der Grund ist einleuchtend: Der Inhalt soll nicht ausgespielt werden, bevor keine Erlaubnis erteilt wurde. Aus der Sicht der Softwareentwicklung ist zu sagen, dass ACL während der Laufzeit zur Verfügung stehen muss, damit er vorm Seitenaufbau genutzt werden kann.

Komposition

Zu guter Letzt werden die letzten Puzzleteile zusammengefügt. Nachdem klar ist an welcher Stelle ACL benutzt werden soll, fehlt der entscheidende  Hinweis wie die Funktionsweise aussieht. Schauen wir nochmal an was wir bis jetzt haben:

  • User-Entität: Benutzer können sich registrieren und einloggen.
  • Rolle-Entität: Es können verschiedene Rollen mit eigener Hierarchie angelegt werden.
  • Rolle-User-Beziehung: Benutzer können verschiedene Rollen bekleiden.
  • Privileg-Entität: Hier werden verschiedene Aktionen, Ressourcen oder Bereiche persistiert. Schlussendlich kommt es hierbei auf den Anwendungsfall an. Dazu später mehr, wenn es um das Mapping geht.
  • Privileg-Rolle-Beziehung: Rollen erhalten Privilegien.

Es sind alle grundlegenden Bausteine für die Implementierung einer Zugangskontrollliste vorhanden. Im letzten Schritt wird die ACL als Service implementiert. Folgendes Zitat beschreibt einen Service als ein Objekt, das komplexe Anwendungslogik ausführt und alle komplizierten Dinge der Anwendung zusammenschnürt und einem leicht verständliche Antworten gibt.

A Service is an object that executes complex application logic. It’s the part of the application that wires all difficult stuff together and gives you easy to understand results.

Zend Framework 2 Documentation

Diese Definition passt auf unser Thema. Im ACL-Service werden Privilegien und Rollen zusammengeführt. Außerdem soll der Service die Funktionalität, ob ein User Zugriff auf die angeforderte Ressource hat, zur Verfügung stellen. Während der Laufzeit wird dem Service der aktuelle User bekannt gemacht. Über die User-Rolle-Beziehung kann die Rolle abgelesen werden.

Das Mapping

Doch woher weiß die ACL welches Privileg für den angeforderten Bereich benötigt wird? Dieses Problem kann vielerlei gelöst werden. Einerseits kann beispielsweise das erforderliche Privileg in dem angeforderten Codeblock verankert werden, das dann beim Gebrauch dem Service übergeben wird. Andererseits kann das zentral im Service selbst gelöst werden, indem ein sogenanntes Mapping stattfindet. Generell ist ein Mapping eine Zuordnung zwischen zwei verschiedenen Modellen. In der Praxis wird dieses Problem oft gelöst, indem eine URL auf ein Privileg „gemappt“ wird. Diese Lösung setzt also voraus, dass jedes Privileg einer Webseite entspricht und funktioniert nur, wenn Funktionalitäten einer Webanwendung konsequent auf ihre Webseiten verteilt wird. Meiner Meinung nach eine sehr gute Lösung, weil jede URL einzigartig und eindeutig ist. Ich möchte hierbei die Lösung nur in Kurzform präsentieren, weil es ausreicht die Idee dahinter zu verdeutlichen.

Dafür das folgende Beispiel: Nehmen wir an, dass ein normaler User ein komplettes Thema aus einem Forum löschen möchte. Laut Konvention darf das aber nur ein Moderator oder Admin. Nun lautet das dafür erforderliche Privileg „ForumThemaLoeschen“. Weil diese Funktionalität in einer eigenen Webseite gekapselt ist, existiert dafür die URL „/forum/thema/loeschen“. Im ACL wird für diese URL auf das zuvor genannte Privileg gemappt. Zum Kontrollzeitpunkt wird dem Service die URL als angeforderte Ressource übermittelt. Intern wird für die Ressource das passende Privileg gesucht. Anschließend wird überprüft, ob die derzeitige Benutzerrolle zugangsberechtigt ist.

Schluss

Gewährt der ACL-Service den Zugang wird die Webseite wie erwartet aufgebaut. Andernfalls greift ein Mechanismus für Zugangsfehler, der entscheidet was als Nächstes passieren soll. Mögliche Szenarien sind Fehlerseiten oder -meldungen sowie Weiterleitungen auf andere erlaubte Ressourcen.

Fazit

Eine ACL ist eine effiziente und gute Lösung für die Erweiterung der bestehenden Benutzerfunktionen um eine Rechteverwaltung. So ist der Kontrollfluss rund um Zugriffs- und Zugangsangelegenheiten stets unter Kontrolle. Ein wichtiger Vorteil ist die Flexibilität: ACL’s passen für jedes Anwendungsgebiet und die Implementation der Zugangskontrolle ist dank Mappings frei realisierbar. Sollte der Service nicht benötigt werden, ist er simpel zu deaktivieren. Wenn die Grundfunktionen nicht den Ansprüchen der Anwendung genügen, kann die Codebasis um die fehlenden Funktionen erweitert werden.

@Tutorial

Demnächst wird es zu diesem Thema ein Tutorial zur konkreten Umsetzung mit PHP geben. Das wird dann selbstverständlich hier nochmal verlinkt 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.