Identitäten und Berechtigungen

Identitäten und Berechtigungen

0:00 Willkommen zu Modul fünf. Lotsenhaus läuft inzwischen reproduzierbar hinter dem Proxy, die Konfiguration liegt in lotsenhaus-betrieb. Jetzt kommt die Frage, an der sich jede Plattform im Unternehmen messen lassen muss: Wer darf eigentlich hinein, und was darf er dort tun? Bei Brandtner Fördertechnik sollen IT, Projektmanagement und interne Kommunikation dieselbe Plattform nutzen, aber nicht dieselben Rechte haben.

0:23 In diesem Modul sortieren wir Rollen, Gruppen und Freigaben, binden die Anmeldung an den Identitätsanbieter an, lassen Eintritt und Austritt ohne Handarbeit laufen und regeln technische Konten. Und wir bauen einen Notausgang für den Tag, an dem die zentrale Anmeldung streikt.

Identitäten und Berechtigungen

0:40 Der zweite Tag hat mit der Installation begonnen, jetzt kommen die Menschen dazu. Der Satz auf dieser Folie bringt es auf den Punkt: Wer Zugriff regelt, regelt Verantwortung. Und er nimmt gleich vorweg, was viele vergessen. Eine saubere zentrale Anmeldung braucht immer auch einen Weg hinein, wenn genau diese Anmeldung einmal ausfällt.

Rollen, Gruppen und Ressourcen

1:00 Bevor wir einen Identitätsanbieter anschließen, müssen wir wissen, was er am Ende eigentlich steuern soll. Also zuerst das Rechtemodell selbst, und mit ihm eine Eigenschaft, die überrascht. Stellen Sie sich ein Bürogebäude vor. Die Systemrolle ist der Hausausweis: Er entscheidet, ob Sie überhaupt hineinkommen und wie viel Grundvertrauen Sie genießen.

1:21 Berechtigungen sind die Schlüssel zu einzelnen Räumen, und Gruppen sind die Schlüsselbretter, an denen diese Schlüssel für ganze Abteilungen hängen. Der wichtige Unterschied zu manchem Gebäude: Es gibt nur Schlüssel, keine Schlösser, die jemanden aussperren. Rechte addieren sich, wer in mehreren Gruppen ist, bekommt alles zusammen. Ein Verbot kennt das Modell nicht. Das klingt nach einem Detail, prägt aber den ganzen Entwurf.

1:45 Und eine gute Nachricht steckt auch darin: Modelle, Wissensbasen, Prompts und Werkzeuge sind zunächst privat, bis jemand sie bewusst freigibt. Drei Rollen, und jede hat eine klare Aufgabe. Interessant ist vor allem die Rolle admin, denn sie umgeht die meisten Prüfungen. Bei Lotsenhaus tragen sie deshalb nur die Gruppe lh-admin und das Notfallkonto. Alle Pilotnutzer aus lh-anwender sind gewöhnliche user und unterliegen den Gruppenrechten.

2:12 Unterschätzt wird oft die dritte Rolle, pending. Sie ist der Wartesaal: Ein Konto existiert, kann aber nichts, bis jemand es freigibt. Genau dorthin gehören neue und deaktivierte Konten. Behalten Sie die Fußzeile im Kopf. Das erste Konto einer frischen Installation wird automatisch admin, und wer diesen Moment verschläft, überlässt die Plattform dem schnellsten Klicker.

2:34 Welche Rolle neue Konten bekommen, legt eine eigene Variable fest. Weil sich Rechte nur addieren, lohnt es sich, Gruppen nach ihrem Zweck zu trennen. Links stehen die Berechtigungsgruppen. Sie schalten Funktionen frei, und niemand darf ihnen Ressourcen freigeben. Rechts die Freigabegruppen, die nur Menschen ordnen: lh-it, lh-projekte, lh-kommunikation.

2:56 Sie bekommen Ressourcen geteilt, tragen aber bewusst keine Funktionsrechte. Warum diese Strenge? Hätte eine Fachgruppe nebenbei das Recht zur Websuche, könnten Sie die Websuche nie mehr zentral für alle abschalten, denn irgendeine Gruppe würde sie wieder freigeben. Die Trennung hält also den Standard schmal und die globalen Schalter wirksam. Das ist ein bisschen mehr Planung am Anfang und erspart später manche Überraschung.

3:21 So sieht die Matrix für den Pilot aus. Lesen Sie sie spaltenweise. Der Standard ist fast überall aus, nur das Hochladen von Dateien bleibt an, weil es zur Textarbeit einfach gehört. Die Gruppe lh-wissen bekommt genau zwei Rechte dazu: Modelle und Wissensbasen pflegen, denn dafür trägt sie Verantwortung. Bemerkenswert ist die Zeile zu den Werkzeugen.

3:42 Auch die Wissensverantwortlichen bekommen sie nicht, weil Werkzeuge laut Doku gleichbedeutend mit Root-Zugriff auf den Server sind. Offene Chat-Links bleiben ebenfalls aus, denn sie verlassen das Unternehmen ohne Anmeldung. Und die Fußzeile erinnert an die Logik von vorhin: Was im Standard steht, kann keine Gruppe wieder wegnehmen.

4:02 Jetzt ein Moment der Ehrlichkeit. Alles, was wir bisher konfiguriert haben, ist logische Trennung innerhalb einer Anwendung. Ein Admin kommt trotzdem an alle Daten, über die Datenbank, den Server oder eine Function mit eigenem Python-Code. Der Schalter, der fremde Chats für Admins ausblendet, ist Höflichkeit, aber laut Doku ausdrücklich keine Sicherheitsgrenze.

4:24 Wer echte Mandantentrennung braucht, bekommt nach Empfehlung der Doku eine eigene Instanz. Und noch eine Grenze: Die Rollen regeln nur, was in Open WebUI passiert. Die Schlüssel zu den Modellanbietern brauchen eigene, minimale Rechte. Das führt direkt zur Anmeldung.

Single Sign-on

4:41 Niemand im Unternehmen möchte ein weiteres Passwort. Und kein Sicherheitsteam möchte eine weitere Benutzerverwaltung. Beides löst dasselbe Prinzip: Die Anmeldung gehört dorthin, wo die Identitäten ohnehin leben. Im Labor spielt Keycloak mit dem Realm brandtner den Identitätsanbieter. Die Anbindung ist im Kern eine Handvoll Zeilen in der .env von lotsenhaus-betrieb, und das Muster ist schnell erklärt.

5:05 Open WebUI muss seine eigene Adresse kennen, damit der Rücksprung nach der Anmeldung funktioniert. Dann bekommt es eine Client-Kennung und ein Geheimnis, das nicht im Klartext steht, sondern aus einer Variablen kommt. Die Scopes legen fest, welche Angaben über die Person mitgeliefert werden, und die erlaubten Domänen sorgen dafür, dass nur Adressen von Brandtner hineinkommen.

5:27 Entscheidend ist die Fußzeile: Ohne die Adresse der Provider-Konfiguration weiß Open WebUI gar nicht, wo Keycloak seine Endpunkte veröffentlicht. OIDC ist nicht der einzige Weg, und diese Tabelle hilft bei der Wahl. Die Logik dahinter: Nehmen Sie den offensten Standard, den Ihr Identitätsanbieter spricht. Im Labor ist das OIDC mit Keycloak, in Produktion der Microsoft-Weg zu Entra ID mit einem Tenant. LDAP bleibt für Umgebungen, die nur ein Active Directory ohne OIDC haben.

5:58 Der vertrauenswürdige Header ist der Sonderfall, wenn ein authentifizierender Proxy davor bereits alles erledigt. Zwei Details aus der Fußzeile kosten sonst Stunden. Es geht nur ein OIDC-Anbieter zur gleichen Zeit. Und bei Entra ID muss der Scope offline_access dabei sein, sonst gibt es keinen Token-Refresh. Eine Frage kommt in jedem Sicherheitsgespräch: Wo ist der zweite Faktor? Die Antwort überrascht manche.

6:25 Open WebUI hat keine eigene Mehrfaktor-Anmeldung, und das ist auch richtig so. Den zweiten Faktor, bedingten Zugriff und den Zustand des Geräts prüft der Identitätsanbieter, im Labor Keycloak und später Entra ID. Eine Anwendung, die das selbst nachbauen würde, wäre nur eine weitere Stelle, die man pflegen muss. Achtung bei LDAP: Dort wird nur das Passwort gegen das Verzeichnis geprüft, ein zweiter Faktor kommt so nicht dazu. Und lokale Konten wie notfall-admin bleiben ohne MFA.

6:55 Deshalb gilt: so wenige wie möglich, Passwort im Tresor, jede Nutzung protokolliert. Vier Fehler, die bei der ersten SSO-Anbindung fast immer auftauchen. Der häufigste ist eine Redirect-URI, die im Identitätsanbieter nur fast stimmt. Fast reicht hier nicht, sie muss exakt auf den Callback-Pfad der Instanz enden. Der zweite stammt oft aus Foren oder generierten Antworten: Variablennamen, die plausibel klingen, aber nicht dokumentiert sind.

7:21 Sie erzeugen keinen Fehler, sie wirken einfach nicht. Der dritte verwirrt im Admin-Panel. Die OAuth-Einstellungen sind dort nur lesbar, wenn die Konfiguration nicht dauerhaft in der Datenbank liegt. Und der vierte zeigt sich erst mit mehreren Instanzen: Ein fehlender oder abweichender geheimer Schlüssel lässt Sitzungen und Anmeldung brechen.

Bereitstellung und Lebenszyklus

7:42 Die Anmeldung steht. Aber Menschen wechseln Abteilungen, und sie verlassen das Unternehmen. Jetzt geht es darum, dass Lotsenhaus diese Bewegungen mitbekommt, ohne dass jemand Listen abgleichen muss. Die Idee hinter diesen Zeilen: Die Wahrheit über Gruppen liegt im Identitätsanbieter, und Open WebUI übernimmt sie bei jeder Anmeldung aus dem Token.

8:04 Der Gruppenabgleich ist eingeschaltet, das automatische Anlegen neuer Gruppen dagegen bewusst aus. Gruppen legt das Plattformteam vorher an, und nur diese werden befüllt. Dasselbe Claim liefert auch die Rolle. Wer in lh-admin steht, wird admin, wer in lh-anwender steht, darf hinein. Und wer in keiner der beiden Gruppen auftaucht, wird an der Tür abgewiesen, wie die Fußzeile sagt.

8:26 Damit ist der Identitätsanbieter die eine Stelle, an der Sie über den Zugang zu Lotsenhaus entscheiden. Diese Tabelle zeigt, was die Anmeldung allein nicht leisten kann. Ohne SCIM erfährt Open WebUI nur dann etwas über eine Person, wenn sie sich anmeldet. Ein Gruppenwechsel wirkt also erst nach erneuter Anmeldung, und beim Austritt sperrt der Identitätsanbieter zwar neue Anmeldungen, bereits ausgestellte Tokens bleiben aber gültig.

8:52 Mit SCIM dreht sich die Richtung um. Der Identitätsanbieter meldet Änderungen aktiv, legt Konten vorab an und setzt sie beim Austritt auf pending, laufende Verbindungen enden. Ein Detail ist wichtig: Lokale Konten wie notfall-admin sieht SCIM gar nicht. Das ist gewollt, heißt aber auch, dass Sie diese Konten weiter selbst im Blick behalten.

9:12 Hier geht es um die Frage, wie lange ein einmal erteiltes Ja gilt. Der Standard der Doku sind vier Wochen, Lotsenhaus setzt einen Arbeitstag. Der rote Faden durch die Tabelle heißt Redis. Ohne lh-redis lässt sich ein Token gar nicht widerrufen, weder beim Abmelden noch nach einer Sperre. Ein Rollenwechsel beendet Live-Verbindungen, widerruft aber kein Token, deshalb beim Austritt zusätzlich sperren. Spannend sind die Ausfälle.

9:38 Fällt der Identitätsanbieter aus, arbeiten laufende Sitzungen weiter, nur neue Anmeldungen scheitern. Fällt Redis aus, lässt die Prüfung Tokens durch und schreibt eine Log-Zeile. Genau diese Zeile sollten Sie überwachen, denn sonst merkt es niemand. Wieder vier typische Fallen. Die erste trifft gerade erfahrene Admins: Sie pflegen eine Gruppe von Hand, und bei der nächsten Anmeldung räumt der Abgleich sie wieder weg, auch bei ihnen selbst.

10:04 Die zweite ist das automatische Anlegen von Gruppen. Dann taucht plötzlich jede Gruppe aus dem Verzeichnis auf, auch solche, die nie jemand für Lotsenhaus vorgesehen hat. Die dritte ist eine Keycloak-Eigenheit. Der Mapper liefert Gruppen gern mit vollem Pfad samt Schrägstrich, und die passen dann zu keiner Gruppe in Open WebUI.

10:23 Und die vierte ist schlicht gefährlich: eine unbegrenzte Gültigkeit für Tokens. Die Doku warnt ausdrücklich davor.

Technische Zugänge und Notfall

10:31 Nicht jeder Zugriff kommt von einem Menschen am Bildschirm. Integrationen brauchen eigene Zugänge, und für den Ernstfall braucht es einen Weg hinein, der nicht vom Identitätsanbieter abhängt. Ein API-Schlüssel ist am ehesten mit einer Vollmacht vergleichbar. Wer ihn vorlegt, handelt im Namen des Kontos, das ihn ausgestellt hat, mit genau dessen Rolle und Gruppenrechten.

10:53 Das Gute daran: Diese Rechte werden bei jeder Anfrage neu geprüft. Ändern Sie die Gruppen des Kontos, ändert sich auch, was der Schlüssel darf. Zwei Eigenschaften sollten Sie kennen. Jedes Konto hat genau einen Schlüssel, und er läuft nicht von selbst ab. Wer ihn vergisst, hat also eine Vollmacht ohne Verfallsdatum in Umlauf.

11:12 Freigeschaltet wird das Ganze zweistufig: global für die Instanz und für Nicht-Admins zusätzlich über die passende Berechtigung. Aus der Vollmacht-Logik folgt der Ablauf fast von selbst. Weil der Schlüssel die Rechte seines Kontos erbt, bekommt jede Integration ein eigenes Konto, und zwar als user, nie als admin. Das Konto landet in einer Berechtigungsgruppe, die Schlüssel erlaubt. Dann schränken Sie ein, welche Pfade ein Schlüssel überhaupt aufrufen darf.

11:39 Der Schlüssel selbst gehört in den Tresor, und seine Rotation steht im Kalender, weil er sonst ewig gilt. Endet eine Integration, wird der Schlüssel gelöscht, nicht erneuert. Beachten Sie die Fußzeile: Die Freigabeliste der Pfade gilt für alle Schlüssel der Instanz, sie ist also die Summe aller Integrationen. Jetzt der Notausgang. Das Konto notfall-admin ist ein ganz normales lokales Konto mit Admin-Rolle, das Passwort liegt im Tresor.

12:06 Damit es funktioniert, muss die Passwort-Anmeldung grundsätzlich eingeschaltet bleiben. Das Formular kann trotzdem unsichtbar sein, im Notfall öffnet ein bestimmter Aufruf es gezielt. Jede Nutzung wird protokolliert, danach wird das Passwort gewechselt. Und, ganz wichtig, der Weg wird regelmäßig auf der Testinstanz geprobt, denn ein Notausgang, den nie jemand benutzt hat, klemmt im Ernstfall.

12:29 Die Fußzeile beschreibt den Zielkonflikt: Wer Passwort-Anmeldungen komplett abschaltet, schließt auch diese Tür. Warum so viel Aufwand für ein einzelnes Konto? Weil die Alternative schlechter ist. Der Notfallzugang ist ein reguläres Konto, niemand muss an der Datenbank oder an der Anmeldelogik herumschrauben. Ein Passwort-Reset direkt in der Datenbank ist zwar dokumentiert, bleibt aber der letzte Ausweg, und dann nur zu zweit.

12:55 Nach der Reparatur gibt es eine klare Reihenfolge: zuerst prüfen, ob SSO wieder trägt, dann das Notfallpasswort wechseln und das Audit-Log sichten. Und da steckt die letzte Falle. Ab Werk schreibt das Audit-Log gar nichts. Ohne mindestens die Stufe METADATA bleibt Ihr Notfall unbelegt, und das ist im Nachgang kaum zu erklären.

Übung

13:16 Jetzt wird es praktisch. Sie binden Lotsenhaus im Labor an Keycloak an und zeigen, dass Ihre Berechtigungen nicht nur auf dem Papier stehen. Eine Berechtigungsmatrix zu schreiben ist leicht. Zu beweisen, dass sie gilt, ist die eigentliche Arbeit, und genau die üben Sie hier. Im Labor ist alles vorbereitet: Keycloak mit dem Realm brandtner und je ein Testkonto für die drei Gruppen.

13:38 Ihre Aufgabe ist, Rollen, Gruppen und Freigaben so einzurichten, dass jeder Eintrag der Matrix durch einen Zugriffstest belegt ist. Das Erfolgskriterium ist streng und gerade deshalb aufschlussreich: Je Gruppe zwei Tests, die gelingen müssen, und zwei, die scheitern müssen. Und am Ende meldet sich notfall-admin auch dann an, wenn die zentrale Anmeldung abgeschaltet ist.

14:00 Der Weg führt von der Technik zum Beleg. Zuerst prüfen Sie den Client in Keycloak und ergänzen die Konfiguration der Laborinstanz. Dann legen Sie die drei Gruppen an und schalten den Abgleich ein. Die Standardrechte setzen Sie schmal, und nur lh-wissen bekommt Modelle und Wissensbasen dazu. Bevor Sie testen, schreiben Sie die Matrix auf, mit erwartetem Ergebnis und Testschritt, sonst prüfen Sie nur, was gerade passiert.

14:25 Danach melden Sie sich mit jedem Testkonto an und vergleichen. Die Fußzeile gilt über die Übung hinaus: Ein fehlendes Recht sehen Sie nur, wenn Sie es versuchen. Im nächsten Modul geht es dann um die Modelle, auf die all diese Menschen zugreifen.