Im Rahmen der Digitalisierung gibt es kaum noch Projekte, die ohne eine Form der digitalen Identität auskommen. Rollen und Rechte spielen in diesem Kontext eine Schlüsselrolle bei der Konzeption und dem Einsatz einer Zugangs- und Zugriffskontrolle auf Anwendungen und Inhalte in der Unternehmens-IT.
Die Trennlinie zwischen externen Portal-Usern und unterstützenden internen technischen Anwendungen für Unternehmensangehörige muss besonders berücksichtigt werden.
Um die geforderte, feine Granularität der Zugriffsrechte auf strukturiert abgelegte Dokumente und Informationen auch unter Performance-Gesichtspunkten gewährleisten zu können, ist ein Modell für Rollen, Rechte und Berechtigungen erforderlich, das der Komplexität der Anforderungen einerseits und der schnellen Verfügbarkeit andererseits Rechnung trägt. Insbesondere im Kontext Ressourcen übergreifender Suchergebnisse muss ein Kompromiss im Zweifelsfall zugunsten einer schnellen Verfügbarkeit ausfallen, um den Anforderungen z.B. an Skalierbarkeit genügen zu können.
In der IT-Welt gibt es im wesentlichen zwei Konzepte, die die Zugriffskontrolle auf Ressourcen regeln:
Die sogenannten Access Control Lists (ACL, “Zugriffssteuerungsliste”) und die Role Based Access Control (RBAC, “Rollenbasierte Zugriffskontrolle”).
Access Control Lists stellen zum Beispiel unter UNIX/LINUX eine Erweiterung der gebräuchlichen Zugriffssteuerung à la “owner-group-other” dar. In diesem Blog-Beitrag werden wir uns aber auf die Role Based Access Control beschränken und einen kurzen Überblick über die wichtigsten Konzepte geben.
Die Rolle als Menge von Einzelrechten
Eine (Benutzer-)Rolle (role) besteht aus einer Menge von einzelnen Rechten (privileges oder authorities). Die Definition von Benutzerrollen ist sinnvoll, weil man auf diese Art und Weise nicht jedem einzelnen Benutzer eine Reihe von Einzelrechten zuweisen muss, die für die Ausübung seiner Tätigkeit nötig sind, sondern lediglich die Rolle. Schon allein das spart erheblichen Verwaltungsaufwand. Besonders zum Tragen aber kommt das Rollenkonzept, wenn einer Rolle Rechte entzogen bzw. Rechte hinzugefügt werden sollen, denn man muss auf diese Art und Weise eben nur die Rolle administrieren, nicht aber die Profildaten eines jeden Benutzers. Auch wenn zum Beispiel ein Mitarbeiter innerhalb eines Unternehmens die Stelle wechselt, so muss ihm lediglich die alte Rolle entzogen und die neue zugewiesen werden.
So erreicht man, dass sowohl Änderungen an den Kompetenzen der einzelnen Mitarbeiter als auch Veränderungen der Geschäftsprozesse jeweils nur an einer Stelle im Berechtigungskonzept aktualisiert werden müssen und dieses dadurch konsistent und übersichtlich bleibt.
Registrieren der Applikation an einem IAM
Wie kann das Rollenkonzept nun implementiert werden? Zunächst einmal kann sich die Applikation beim Deployment am Identity Access Management registrieren und dabei die eigenen Rollen und Rechte mitbringen:
Die Rollen und Authorities einer Applikation können aber auch durch Administration im IAM manuell editiert werden.
Wie verfährt man dann bei einem erneutem Deployment der App? Wenn die Änderungen, die in der Applikation an den Rollen und Rechten vorgenommen wurden, einfach im IAM übernommen werden, dann würden vorher erfolgte manuelle Änderungen überschrieben werden.
Wir haben uns deswegen bei unserer Implementierung des IAM dafür entschieden, dass manuelle Änderungen der Rollen/Rechte erhalten bleiben, aber auch die seitens der Applikation gelöschten Rollen/Rechte automatisch im IAM entfernt werden.
Die Applikation kann nun Berechtigungen über Roles/Authorities im Login-Token prüfen
Die Applikation kann nun vor der Ausführung aller Funktionen prüfen, ob die erforderliche Berechtigung für die jeweilige Funktion vorhanden ist. Außerdem kann sie die Benutzeroberfläche an die Benutzerrolle anpassen, z.B. durch Ausblenden von Schaltflächen, deren Funktionalität nicht “erlaubt” ist.
Rollenwechsel
In vielen Fällen kann es sinnvoll sein, wenn ein User mehrere Rollen haben kann. In diesem Fall erhält der User beim Login seine Default-Rolle, die er dann später über die Applikation in eine andere Rolle tauschen kann. Mehrere Rollen sind zum Beispiel dann erforderlich, wenn man für einige Aufgaben Admin-Rechte braucht und bei der normalen Arbeit aber nur ein eingeschränktes oder auch unterschiedliches Rechteset benötigt.
Der Rollenwechsel erfolgt dann so ähnlich wie beim initialen Login-Authentication-Flow: Der User wählt an der UI der Applikation die neue Rolle aus, die Applikation fragt den Rollenwechsel am IAM an, falls der User die andere Rolle haben darf, dann wird die Rolle gewechselt, indem ein neues Access-Token mit dem Rechte-Set der anderen Rolle zurückgegeben wird.
Lessons learned
Jedes System zur digitalen Zugangs- und Zugriffskontrolle hat, neben den allgemeinen und etablierten Standardanforderungen, spezifische, branchentypische Bedürfnisse, die ein IAM-System abbilden (können) muss.
Alle Projekte sind daher mit einer sorgfältigen Anforderungsanalyse zu begleiten, um sowohl funktionale Anforderungen (Sprach-Stacks, Geräteabhängigkeiten, Prüfensembles etc.), als auch nichtfunktionale Anforderungen (Oberflächengestaltung, Reaktionszeiten der Applikation,…) abbilden zu können.
Wie wir gesehen haben ist die Balance zwischen einem hohen Automatisierungsgrad und manueller Steuerung des Identity- und Access Managements ein wesentlicher Bestandteil für die Nutzbarkeit und Akzeptanz eines Identity- und Access Management Systems.