Softwaresysteme für Multiprojektmanagement sind komplex – zumindest hinter den Kulissen auf der technischen Seite. Eine Vielzahl von Funktionen ist bereitzustellen, für die Planung von einzelnen Projekten, Verwaltung von Tasks, Erstellung von Rapporten, um nur einige zu nennen. Gleichzeitig arbeitet nicht bloss ein Anwender damit. Nein, typischerweise sind es Dutzende von Benutzern, die sich alle diese Funktionen und die Daten im System teilen und oftmals zeitgleich und von unterschiedlichen Standorten aus damit arbeiten. Und natürlich soll die Anwendung für alle Beteiligten "super einfach" in der Bedienung sein und eine hervorragende Benutzerfreundlichkeit aufweisen, gemäss Anforderungen des Business natürlich.

Multiusersysteme benötigen ein Berechtigungskonzept

Mit dieser Ausgangslage erstaunt es nicht, dass das gesuchte Softwaresystem ein flexibles aber auch einfach durchschaubares Berechtigungskonzept aufweisen muss. Was verstehen wir darunter? Im Kontext eines Softwaresystems definiert ein Berechtigungskonzept einfach ausgedrückt,

1. welcher Benutzer
2. auf welche Daten
3. was für eine Art des Zugriffs hat.

Da stellen sich gleich einmal mehrere Verständnisfragen, die erläutert werden müssen. Der Benutzer des Systems muss zuerst einmal vom System identifiziert werden. Wir sprechen hier auch von der Authentifizierung. Der Benutzer meldet sich am System an, indem er sagt, wer er ist und das System ihn auffordert, dies zu beweisen. Das tönt kompliziert, wir machen dies aber täglich mehrmals, indem wir unseren Benutzernamen und ein Passwort dazu in ein Login-Fenster eingeben. Mit dem Benutzernamen sage ich dem System, wer ich bin, und mit dem Passwort erbringe ich den Beweis dazu. Dieser einfache Prozess nennt sich Authentifikation. Wenn wir etwas mehr Sicherheit ins Spiel bringen wollen, dann verlangen wir vom Benutzer noch etwas mehr Beweiskraft, indem wir ihn z.B. auffordern, einen zusätzlichen Einmal-Code einzutippen, den das System ihm auf sein Mobiltelefon schickt. Hier sprechen wir dann von 2-Faktoren-Authentifizierung. Aber dies ist nicht das Thema hier.

Was sind überhaupt Berechtigungen?

Mit der Authentifizierung wissen wir nun schon mal, wen wir vor uns haben. Aber was darf dieser Benutzer nun im System tun? Dafür kommt die Autorisierung hinzu, also das Zuteilen von Berechtigungen im Bezug auf die im System enthaltenen Daten und Funktionen. Nun wird es (zumindest aus Sicht der Technik) etwas komplizierter. Grundsätzlich macht man das so, dass man eine Grundmenge von Berechtigungen (auch Rechte oder auf Englisch Permissions genannt) definiert. Aus diesem Topf weist man dann dem Benutzer eine Anzahl Berechtigungen zu. So weit so gut. Nur: Was ist denn eine Berechtigung konkret?

Dies ist die erste grosse Herausforderung in diesem Thema. Eine Berechtigung kann auf viele unterschiedliche Arten definiert werden. Einige Beispiele:

• ein Projekt einsehen
• einen Task verändern
• einen Report generieren
• einen neuen Benutzer anlegen
• eine Berechtigung vergeben

Gerade das letzte Beispiel zeigt, dass Berechtigungen sogar rekursiv wirken: Wir können Berechtigungen definieren, welche es erlauben, weitere Berechtigungen zu erteilen... Aber auch die ersten paar Beispiele sind interessant, weil sie uns aufzeigen, dass eine Berechtigung in der Regel auf ein Objekttyp wirkt (ein Projekt, ein Task, ein Report etc.) und eine Aktion umfasst (einsehen, verändern, generieren etc.). Grundsätzlich können wir also einfach alle Datenobjekttypen in unserem System aufführen und dazu alle möglichen Aktionen nehmen. Kombinationen daraus ergeben dann die Grundmenge von Berechtigungen. So einfach sich das schreiben lässt, so komplex ist das aber in der Realität. Bereits in einfachen Datenhaltungssystemen sind Dutzende von Objekttypen enthalten und viele verschiedene Aktionen darauf möglich. Die einfache Multiplikation dieser Mengen führt zu einer Explosion von Möglichkeiten. Kommt erschwerend hinzu, dass man natürlich gerne auch Berechtigungen auf einzelnen Objekten (also Instanzen von Objekttypen) erteilen möchte. Z.B. "Projekt X ändern", nicht generell "Projekte ändern". Dies bringt nochmals eine neue Komplexitätsdimension hinein.

Diese Unmenge an Berechtigungen muss gut strukturiert werden, um sie in den Griff zu bekommen und den Überblick zu behalten. Was wir tun können, ist z.B. Folgendes. Berechtigungen können in einer Baumstruktur in Beziehung zu einander gebracht werden. Eine Berechtigung B kann als Ast einer Berechtigung A definiert werden. Damit drücken wir aus, dass wenn ein Benutzer B darf, dann darf er implizit auch A. Wieder ein simples Beispiel: "B = ein Projekt verändern" und "A = einen Task verändern". Wenn ein Benutzer ein Projekt veränden darf, dann soll er also implizit auch alle enthaltenen Tasks verändern. Ähnlich kann man dies mit Aktionen machen: "B = ein Projekt verändern" und "A = ein Projekt einsehen". Auch hier impliziert die Berechtigung B die Berechtigung A, d.h. wenn jemand ein Projekt verändert darf, dann darf er es auch einsehen (klar doch).

Wie kommt nun ein Benutzer zu seinen Berechtigungen?

Nehmen wir also einfach mal an, dass wir die Grundmenge an Berechtigungen definiert und strukturiert haben und somit kennen. Wie teile ich diese nun einem Benutzer zu? Auf den ersten Blick könnte man eine direkte Zuteilung machen. Also z.B. "Benutzer Meier hat die Berechtigungen B, D, E und H". Dies ist einfach verständlich – aber bloss, weil das Beispiel so trivial ist. Auch hier liegt die Komplexität in der schieren Menge an möglichen Kombinationen. Wenn wir Dutzende oder gar hunderte von Benutzern haben und dazu um ein Vielfaches mehr Berechtigungen, dann müssen wir uns mit exorbitant grossen Berechtigungstabellen herumschlagen. Der Überblick ist dann garantiert weg. Das Problem kann man beseitigen, wenn man sich mit nur einer kleinen Grundmenge an Berechtigungen zufrieden gibt. Aber aus der Erfahrung können wir sagen, dass jeder Käufer von solchen Softwaresystemen soviel Flexibilität im Bezug auf "Steuern und Kontrolle der Zugriffe" fordert, dass wir eine bessere Lösung benötigen.

Die bessere Lösung ist die, die mit Rollen arbeitet. Dieser Lösungsansatz stammt aus den frühen 90er Jahren und hat sich in der Praxis bewährt. Er kommt in vielen, wenn nicht den meisten Datenhaltungssystemen zum Einsatz. Man kennt diesen Ansatz unter dem englischen Begriff Role-Based Access Control (RBAC). Das Prinzip lässt sich so erläutern: Wir definieren verschiedene Rollen (z.B. Projektleiter, Portfoliomanager, Systemadministrator) und teilen diesen Rollen dann Berechtigungen zu. Erst dann nehmen wir die Benutzer und geben ihnen eine oder auch mehrere Rollen. So kommen die Benutzer indirekt über ihre Rollen zu den Berechtigungen. Dieses Prinzip hat den grossen Vorteil, dass ich das Zusammenspiel zwischen Benutzern und Berechtigungen einfacher handhaben kann, insbesondere im Falle von Änderungen. Und die gibt es ja bekanntlich öfters mal. Wenn ich somit den Projektleitern die Berechtigung zum Verändern von Projekten entziehen möchte, dann löse ich dies auf der Rolle "Projektleiter". Alle Benutzer mit dieser Rolle haben dann sofort die veränderten Berechtigungen.

Die richtige Struktur ist also gefragt

Es ist die Unmenge an Möglichkeiten, Berechtigungen zu definieren und Benutzern zuzuteilen, welche die Thematik so komplex macht. Mit einer ausgeklügelten Struktur, eben einem guten Berechtigungskonzept, können wir dieser grossen Herausforderung aber beikommen. Die obigen Ausführungen kratzen bloss an der Oberfläche des Themas und mit dem einfachen Beispiel der Einführung von Rollen soll keineswegs der Eindruck vermittelt werden, dass dies der Weisheit letzter Schluss ist. Es ist ein möglicher und guter Ansatz. Was wir hier auch nicht angesprochen haben, ist die Visualisierung der ganzen Systemzustände und Funktionalitäten aus Sicht der Anwender. Wie kann ein Systemadministrator die Benutzer, Rollen und Berechtigungen einfach pflegen und sich immer sicher sein, auch wirklich die richtigen Einstellungen vorgenommen zu haben? Wir werden in einem zukünftigen Artikel dieser Frage auf den Grund gehen und anhand von PQFORCE zeigen, wie wir dies lösen. Bleiben Sie also dran.