Ausblick auf das kommende Rollendesign in UCS und UCS@school

Seit unserem letzten Beitrag zum zukünftigen Rollenmodell haben wir bedeutende Fortschritte bei der Weiterentwicklung des Rollen- und Rechtemodells von UCS erzielt. Das Design der individuellen Rollengestaltung, das sich aktuell in der Entwicklung befindet, nimmt konkrete Form an.

In diesem Artikel möchten wir uns auf die Vorstellung von zwei vielversprechenden neuen Komponenten konzentrieren: Eine davon ermöglicht die Auswertung von Berechtigungen einer Rolle, während die andere ein Webmodul darstellt, das es Ihnen ermöglicht, eigene Rollen zu erstellen. Blicken wir gemeinsam auf das, was uns bis zum Ende des Jahres noch erwartet.

Die Hand, die über alles wacht – der ‘Guardian’

Das zentrale Herzstück des neuen Rollenmodells bildet eine technische Komponente, die zukünftig von allen Modulen konsultiert wird, um die jeweiligen Berechtigungen von Nutzenden zu ermitteln. In dieser Komponente, dem Guardian, ist der Open Policy Agent eingebunden, dessen Funktion schon im Beitrag Starrsinn steht uns nicht: Univention bricht Rollenmodell von UCS und UCS@school auf im März mit einigen Funktionen vorgestellt wurde. Weitere Aufgaben, die Guardian ebenfalls erfüllt, möchte ich im Folgenden kurz anreißen.

Soll in einem Modul oder einer Anwendung eine Aktion stattfinden, so wird der Guardian angefragt, um eine Auswertung anhand der Berechtigungen vorzunehmen, die ein oder eine Nutzer*in für dieses spezielle Modul oder diese Anwendung hat. Dabei ist es nicht die Aufgabe der Komponente, eine Richtlinie in dem jeweiligen Modul selbst durchzusetzen, sondern dem jeweiligen Modul ein simples ist „zugelassen“ oder „nicht zugelassen“ zurückzuspielen.

Aber auch komplexere Anfragen können verarbeitet werden, wie zum Beispiel eine Anfrage nach einer Auflistung aller Berechtigungen, die ein oder eine Nutzer*in für ein bestimmtes Modul oder eine Applikation hat. So kann die Oberfläche des Moduls bzw. der Applikation entsprechend gestaltet werden, damit nur die Aktionen und Attribute sichtbar sind, mit denen der oder die Nutzer*in auch arbeiten darf.

Außerdem bietet der Guardian Schnittstellen, um Rollen anzulegen und zu modifizieren. Dies bildet die Grundlage für ein Web-Interface eines Rollenmoduls, das es Administrierenden ermöglicht, eigene Rollen zu erstellen und komfortabel über das Web-Interface anzulegen. Im nächsten Abschnitt werden wir genauer darauf eingehen, wie ein solches Modul aussehen wird.

Ein eigenes Modul zur Gestaltung von Rollen

Im Rahmen der Arbeit am Guardian ist ein Webmodul im Entstehen, das sich eigens dem Design von Rollen annimmt und eine wesentliche Funktion des Guardian für Sie nutzbar machen wird.

Mockup des Rollenmoduls

In dem Interface können Sie alle Aspekte einer Rolle verwalten. Von der Anlage einer Rolle, über die Definition ihrer Fähigkeiten, bis hin zum Kontext und dem Namensraum, in dem sich Rollen bewegen dürfen. Der Kontext ist insbesondere dann wichtig, wenn ein Benutzer nur berechtigt ist, andere Benutzer aus der eigenen Unterorganisation, Abteilung oder Schule zu verwalten. Im Falle von UCS@school ist der Kontext also gleichbedeutend mit der Schule. Der Namensraum (Namespace) dient der übersichtlicheren Organisation der Rollen.

Im einfachsten Fall legen Sie einen eigenen Namespace für die von Ihnen individuell erstellten Rollen an und können die Standard-UCS-Rollen von Ihren eigenen unterscheiden. Verwalten Sie viele Abteilungen oder Schulen oder haben Sie viele Apps im Einsatz, dann ist es sehr wahrscheinlich, dass Sie z. B. die Rolle „Administrator“ mehr als einmal pflegen müssen. Namensräume helfen hier den Überblick zu behalten, z. B. indem Sie eigene Namensräume pro App (Nextcloud, OX, usw.) oder pro Schulform (Gymnasium, Berufsschule, usw.) erstellen.

Aber wie werden nun Berechtigungen zugewiesen? Auf der Detailseite einer Rolle lassen sich die Fähigkeiten dieser Rolle definieren. Eine Fähigkeit besteht aus zwei Teilen: Einer Berechtigung und einer Bedingung, wann diese Berechtigung in Kraft tritt. Dabei kann eine Rolle viele Fähigkeiten haben. Lassen Sie mich das an einem Beispiel erklären:

Sie legen eine Rolle „Sachbearbeiter*in“ an, die sich im Kontext der Schule „SchoeneSchule“ bewegt. Diese Rolle darf die Passwörter aller Lehrkräfte zurücksetzen, sofern diese ebenfalls zu „SchoeneSchule“ gehören.

Um das umzusetzen, erstellen Sie für die Rolle „Sachbearbeiter*in“ eine neue Fähigkeit mit den Bedingungen:

1. 1. „Zielobjekt hat die Rolle ‚Lehrkraft‘“ und
   2. „Zielobjekt ist an der gleichen Schule wie ich“
      und definieren dann die damit verbundene Berechtigung: „darf Passwort zurücksetzen“.

Das folgende Mockup veranschaulicht dieses Beispiel:

Mockup zeigt exemplarisch, wie Fähigkeiten einer Rolle im Frontend von UCS@school festgelegt werden könnten.

Fähigkeiten, die in dem Rollenmodul vergeben werden können, werden von den jeweiligen Modulen und Applikationen zugeliefert. Auch die UCS-Module müssen daher so angepasst werden, dass ihre Fähigkeiten dem Guardian bekannt werden. Nur dann werden sie auch im Rollenmodul verfügbar. Der Umfang wird zum ersten Release beschränkt sein und in den folgenden Monaten weiter ausgebaut.

Erste Einsatzmöglichkeiten

Das erste Release des Guardians und dem zugehörigen Rollenmodul ist für Ende des Jahres geplant. Es wird sich um eine Alpha-Variante handeln, die sich über das nächste Jahr weiterentwickeln wird. Daher empfehlen wir, diese Komponenten vorerst nur in den eigenen Test-Systemen zu installieren, um erste Einsatzszenarien zu konzipieren. Ein paar mögliche Szenarien will ich hier an Beispielen erläutern.

Für den ersten Wurf des Rollenmoduls haben wir uns dafür entschieden, Aktionen und Fähigkeiten des neuen Schulbenutzermoduls verfügbar zu machen, welches wir ebenfalls Ende des Jahres ausliefern werden. Somit werden als Erstes unsere UCS@school-Kunden von den Entwicklungen profitieren können.

Ein Szenario, das sich mit dem neuen Modul umsetzen ließe, ist die Erstellung von Rollen, die Schulbenutzer modifizieren, aber nicht anlegen oder löschen können. Ein weiteres, Fähigkeiten auf bestimmte Kontexte einzugrenzen, z. B. dass eine Rolle „Bezirks-Admin“, Schulbenutzer an den drei Schulen anlegen, löschen oder modifizieren darf, die in seinem oder ihrem Bezirk liegen. Oder dass eine Rolle „Schul-Admin“ nur Schulbenutzer an der eigenen Schule anlegen, löschen und modifizieren darf.

Weniger offensichtlich, dafür aber umso praktischer, ist folgendes Szenario: Sie können den verschiedenen Akteuren im Schulbetrieb bessere Übersichten einräumen. Beispielsweise können Sie „Schul-Admins“, die im Benutzermodul zu viele Informationen über die einzelnen Nutzer*innen erhalten würden und im herkömmlichen Schulbenutzermodul zu wenige, eine passgenaue Ansicht zugänglich machen.

Das geht, indem Sie im Rollenmodul festlegen, welche der Attribute von den ‚Schul-Admins‘ gelesen und welche modifiziert werden dürfen. Eine Person mit dieser Rolle wird dann im neuen Schulbenutzermodul ausschließlich die von Ihnen festgelegten Attribute einsehen und editieren können, während alle anderen Werte als „geheim“ dargestellt werden.

Beispielhafte Darstellung im neuen Schulbenutzermodul, wenn eine Rolle nicht das Recht hat, den Vor- und Nachnamen zu lesen.

Ein paar letzte Worte

Wir freuen uns schon auf das Release der neuen Funktionen des Rollen- und Rechtemodells Ende des Jahres und sind sehr gespannt, welche Einsatzszenarien Sie als Erstes damit umsetzen werden. Teilen Sie uns und anderen UCS- und UCS@school-Nutzer*innen gerne Ihre Ideen für Anwendungsfälle als Kommentar mit.

Wenn Sie aktiv an der weiteren Entwicklung der Rollengestaltung mitwirken möchten und zu den Ersten gehören wollen, die ihr Feedback mit uns teilen, zögern Sie nicht, mich persönlich zu kontaktieren. Nach der Veröffentlichung der Module werden wir Sie dann eng in den Entwicklungsprozess einbeziehen und freuen uns auf Ihre wertvollen Beiträge. Gemeinsam gestalten wir eine noch effektivere und benutzerfreundlichere Lösung. Vielen Dank für Ihre Unterstützung!