Nextcloud und SAML die stille Macht im Hintergrund

Die stille Macht im Hintergrund: Nextcloud und SAML-Authentifizierung

Wenn IT-Verantwortliche über die Absicherung ihrer Kollaborationsplattform sprechen, fällt früher oder später der Begriff SAML. Oft schwingt dabei eine gewisse Ehrfurcht mit, manchmal auch Ratlosigkeit. Nextcloud, die selbstgehostete Cloud-Lösung, die in deutschen Unternehmen und Behörden längst zum festen Inventar gehört, unterstützt SAML-Authentifizierung bereits seit Jahren. Doch was bedeutet das konkret? Und vor allem: Was bedeutet es für den Admin, der das Ganze zum Laufen bringen soll, für die Security-Abteilung, die ihre Richtlinien durchsetzen will, und letztlich auch für die Nutzer, die sich nur noch mit ihrem gewohnten Account anmelden möchten, ohne ständig nach Passwörtern gefragt zu werden?

Man kann es drehen und wenden, wie man will: SAML ist im Enterprise-Umfeld nach wie vor der Standard, wenn es um Single Sign-On geht. Das hat historische Gründe, aber auch praktische. Während OpenID Connect und OAuth 2.0 in der Webwelt dominieren, setzen viele etablierte Identity Provider wie Microsoft Active Directory Federation Services, Shibboleth oder auch das in Europa weit verbreitete Keycloak gleichermaßen auf SAML. Und Nextcloud kann sich mit all diesen Systemen verständigen. Das ist kein Selbstläufer, aber es funktioniert, wenn man die grundlegenden Mechanismen versteht. Der folgende Artikel versucht, genau dieses Verständnis zu vermitteln – ohne Anspruch auf ein vollständiges Handbuch, aber mit dem Blick für die Stolperfallen, die einen im Alltag erwarten.

SAML in zehn Sätzen oder: Warum der Vertrauenskreis funktioniert

Bevor wir uns in die Tiefen der Nextcloud-Konfiguration begeben, lohnt ein kurzer Blick auf das Protokoll selbst. SAML, genauer SAML 2.0, ist ein XML-basierter Standard für den Austausch von Authentifizierungs- und Autorisierungsdaten. Es gibt zwei Parteien: den Identity Provider, kurz IdP, und den Service Provider, hier also die Nextcloud-Instanz. Der IdP kennt die Benutzer, prüft ihre Identität und stellt dem Service Provider eine sogenannte Assertion aus. Diese Assertion ist im Grunde ein digital signiertes Dokument, das besagt: Dieser Nutzer hat sich erfolgreich angemeldet, und zwar mit diesen Attributen, diesen Gruppen, dieser Berechtigung.

Der entscheidende Punkt ist, dass das Passwort niemals den Weg zum Service Provider findet. Die Nextcloud erfährt lediglich, dass der Nutzer sich beim IdP ausgewiesen hat. Das klingt banal, hat aber weitreichende Konsequenzen: Selbst wenn die Nextcloud-Instanz kompromittiert wird, sind die Zugangsdaten der Nutzer nicht in Gefahr. Der Angreifer müsste schon den IdP angreifen, was eine ganz andere Hausnummer ist. Genau dieser Architekturgedanke macht SAML so attraktiv für Unternehmen, die ihre Zugangsdaten nicht in jeder einzelnen Anwendung vorhalten wollen.

Dabei zeigt sich allerdings schnell: Der Teufel liegt im Detail. SAML ist kein Protokoll im Sinne von HTTP, bei dem man einfach eine Anfrage schickt und eine Antwort bekommt. SAML lebt von Vertrauensbeziehungen, von Metadaten, von Zertifikaten und von exakt abgeglichenen Einstellungen auf beiden Seiten. Ein einziger falscher Attributname, ein abgelaufenes Zertifikat, ein falsch konfiguriertes Binding – und die Anmeldung schlägt fehl, oft mit wenig aussagekräftigen Fehlermeldungen. Das führt zu jenen Support-Tickets, die niemand liebt und die trotzdem jeder kennt.

Nextcloud und die SAML-Integration: Wie es zusammenspielt

Nextcloud bringt die SAML-Unterstützung über die App „user_saml“ mit. Diese App ist keine Spielerei, sondern eine der zentralen Säulen für Enterprise-Deployments. Sie basiert, das sei der Fairness halber erwähnt, auf der OneLogin-PHP-SAML-Library, was manchen Administrator zunächst stutzen lässt, weil dadurch Abhängigkeiten entstehen, die man nicht selbst in der Hand hat. Doch in der Praxis hat sich dieser Unterbau über die Jahre bewährt. Die App erlaubt es, Nextcloud als Service Provider an praktisch jeden SAML-2.0-konformen Identity Provider anzubinden – vom simplen Test-IdP bis hin zum komplexen Verbund mit mehreren hunderttausend Nutzern.

Interessant ist dabei, dass Nextcloud nicht zwingend die klassische Rollenverteilung vorschreibt. Man kann die App so konfigurieren, dass sie nur einen einzigen IdP anspricht, was im Normalfall der einfachste und sicherste Weg ist. Es gibt aber auch Konstellationen, in denen mehrere IdPs angesprochen werden sollen, beispielsweise nach einer Firmenfusion, wenn zwei getrennte Benutzerwelten zusammengeführt werden, ohne die Konten bereits zu vereinheitlichen. Das ist prinzipiell möglich, erfordert dann aber eine deutlich komplexere Konfiguration, die an dieser Stelle nur angerissen werden kann. Die meisten Installationen kommen mit einem IdP aus, und darauf sollte man sein Augenmerk richten.

Die Konfiguration selbst erfolgt überwiegend über die Nextcloud-Konfigurationsdatei config/config.php oder über die Verwaltungsoberfläche, je nachdem, welche Version man einsetzt und wie die Richtlinien im Unternehmen es vorsehen. In der Praxis bewährt sich ein hybrides Vorgehen: Grundparameter, etwa die Endpunkt-URLs und die Zertifikate, werden in der Konfigurationsdatei fixiert und sind damit für die Admin-Oberfläche gesperrt. Das verhindert, dass ein Administrator – aus welchen Gründen auch immer – versehentlich grundlegende Sicherheitseinstellungen verändert. Feintuning, etwa die Zuordnung von Attributen, kann dann über die UI erfolgen, wenn man dies möchte.

Die Frage der Metadaten: Eine kleine Reise in die Welt der XML-Dokumente

Wer sich zum ersten Mal mit SAML beschäftigt, wird unweigerlich mit dem Begriff „Metadaten“ konfrontiert. Dahinter verbirgt sich ein XML-Dokument, das die technischen Eigenschaften eines Dienstes beschreibt: Endpunkte, unterstützte Bindings, Zertifikate, Signaturen. Jeder IdP publiziert solche Metadaten, und auch Nextcloud kann sie ausliefern, sobald die SAML-App aktiviert ist. Der Weg dorthin führt in der Regel über einen Endpunkt wie /apps/user_saml/saml/metadata.

Der elegante Weg ist, diese Metadaten direkt auf der IdP-Seite zu importieren. Keycloak bietet dazu einen komfortablen Importdialog; ADFS verlangt etwas mehr Handarbeit. Dabei sollte man wissen: Die Metadaten von Nextcloud sind generiert und enthalten die öffentlichen Schlüssel des Service Providers. Sobald man die Zertifikate auf Nextcloud-Seite rotiert, ändern sich die Metadaten. Das kann zu einem bösen Erwachen führen, wenn der IdP weiterhin mit dem alten Zertifikat rechnet. In der Praxis heißt das: Zertifikatswechsel müssen sauber geplant werden, mit einer Übergangsphase, in der beide Schlüssel akzeptiert werden. Nextcloud bietet dafür Optionen, die jedoch konfiguriert werden müssen.

Ein typischer Anfängerfehler ist übrigens der, die Metadaten des IdP in Nextcloud einzutragen, statt die Nextcloud-Metadaten im IdP zu registrieren. Zugegeben, die Beschriftungen in den Administrationsoberflächen sind nicht immer eindeutig. Aber wer sich vor Augen hält, dass jeder Dienst seine eigenen Metadaten hat und beide Seiten einander vertrauen müssen, kommt selten durcheinander.

Die Attribute: Wo die Daten herkommen und wie man sie zuordnet

Der wichtigste Teil der SAML-Integration ist zweifellos das Attribut-Mapping. Wenn sich ein Benutzer anmeldet, sendet der IdP in der Assertion bestimmte Attribute mit. Mindestens eines davon muss die Nextcloud in einen lokalen Benutzernamen übersetzen. Dieses Attribut wird häufig uid genannt, bei ADFS kann es auch nameid oder upn sein, in anderen Umgebungen schlicht mail. Die Kunst besteht darin, ein Attribut zu wählen, das eindeutig ist und sich nicht im Laufe der Zeit ändert. Die E-Mail-Adresse mag auf den ersten Blick gut geeignet sein, aber was passiert bei einer Heirat oder einer Umbenennung der Firma? Der Benutzername bleibt meist stabil, die E-Mail nicht. Also besser ein unveränderliches Attribut nehmen, sofern es eins gibt – und das ist in den meisten Verzeichnisdiensten der Fall.

Neben dem Benutzernamen werden üblicherweise Anzeigename, E-Mail-Adresse und Gruppen übermittelt. Nextcloud kann diese Informationen übernehmen und daraus lokale Benutzerprofile erstellen. Das geschieht automatisch bei der ersten Anmeldung, ein Vorgang, der als Just-in-Time-Provisioning bezeichnet wird. Der Nutzer existiert vorher nicht in der lokalen Datenbank der Nextcloud, er wird quasi aus der SAML-Assertion heraus geboren. Für den Administrator ist das ein Segen, denn die lästige Anlage von Konten entfällt. Es birgt aber auch ein Risiko: Wenn die Attributpflege im IdP schludert, beispielsweise weil Gruppen nicht korrekt gepflegt werden, kann es passieren, dass Nutzer zwar Zugang erhalten, aber mit falschen Berechtigungen. Die Qualität einer SAML-Anbindung steht und fällt also mit der Datenqualität im Identity Provider.

Ein interessanter Aspekt ist in diesem Zusammenhang die Behandlung von lokalen Nextcloud-Attributen. Angenommen, ein Nutzer hat bereits lokale Daten, etwa Adressbuch-Einträge oder Kalender, bevor die SAML-Anbindung aktiviert wird. Wie werden diese mit den SAML-Attributen abgeglichen? In der Regel gleicht Nextcloud den Benutzernamen ab: Wenn der SAML-uid dem lokalen Benutzernamen entspricht, werden die Daten demselben Nutzer zugeordnet. Dazu muss man jedoch unbedingt sicherstellen, dass die lokalen Konten eine Übereinstimmung mit den SAML-Attributen haben. Sonst erzeugt man sich eine Benutzerlandschaft mit Dubletten, und die Daten sind über mehrere Konten verstreut. Das ist eine der häufigsten Ursachen für Chaos nach einer SAML-Einführung.

Gruppen und Berechtigungen: Ein heikles Thema

Gruppen sind in Nextcloud das wichtigste Mittel, um Ordnung zu schaffen. Man denke an Freigaben, an den Zugriff auf interne Dateien, an die Sichtbarkeit von Ordnern und an die Konfiguration von Speicherkontingenten. Über SAML-Gruppenattribute lassen sich diese Berechtigungen zentral im Identity Provider steuern. Das klingt verlockend, entpuppt sich in der Praxis jedoch als eine der kniffligsten Aufgaben.

Die Herausforderung liegt in der Natur der Sache: Gruppen werden in unterschiedlichen Systemen unterschiedlich benannt. In Active Directory heißt eine Gruppe vielleicht „FI-Abteilung“, im IdP wird sie als „finance_team“ geführt, und in Nextcloud soll daraus womöglich „Finance“ werden. SAML selbst definiert keine feste Struktur für Gruppen – es transportiert lediglich eine Liste von Werten in einem Attribut, häufig groups oder memberOf. Nextcloud muss diese Werte in lokale Gruppennamen übersetzen. Dazu kann man ein Mapping konfigurieren, das den SAML-Gruppennamen auf einen lokalen Nextcloud-Gruppennamen abbildet. Ist das Mapping sauber angelegt, werden Benutzer automatisch in die entsprechenden Gruppen einsortiert. Sie können diese Gruppen dann nicht selbst verlassen, solange das SAML-Attribut sie dort hineinlegt – ein Aspekt, der vielen Nutzern erst auffällt, wenn sie versuchen, die Gruppe in ihren Einstellungen zu wechseln oder zu verlassen. Das ist kein Bug, sondern ein Feature, das die zentrale Steuerung durch die IT-Abteilung sicherstellt.

Natürlich gibt es auch lokale Gruppen, die nichts mit SAML zu tun haben. Diese können weiterhin manuell verwaltet werden. Das führt allerdings zu der Frage, wie sich lokale und SAML-Gruppen zueinander verhalten, insbesondere wenn ein Benutzer über SAML einer Gruppe zugeordnet wird, die lokal bereits existiert. Nextcloud legt die Gruppe bei Bedarf an, wenn sie noch nicht existiert. Dabei ist es von Vorteil, dass SAML-Gruppen meist als schreibgeschützt markiert werden, damit sie nicht versehentlich in der Nextcloud-UI bearbeitet werden. Sonst passiert genau das, was passieren muss: Ein Admin löscht eine Gruppe, der nächste SAML-Login legt sie wieder an, das Chaos ist perfekt.

Single Sign-On und die Krux mit dem Logout

Der Hauptgrund, warum Unternehmen auf SAML setzen, ist das Single Sign-On, kurz SSO. Der Nutzer muss sich genau einmal am IdP anmelden und hat danach Zugriff auf alle Dienste, die diesem IdP vertrauen. Im besten Fall bedeutet das: Man loggt sich morgens am Rechner ein, und Nextcloud fragt kein Passwort mehr ab. Das ist komfortabel und erspart nicht nur Zeit, sondern auch das berüchtigte Passwort-Wirrwarr, das die Helpdesks überflutet.

Die Kehrseite der Medaille ist der Single Logout, kurz SLO. Wenn sich ein Nutzer aus der Nextcloud abmeldet, sollte idealerweise auch die Sitzung am IdP beendet werden. Sonst passiert das, was man von manchen Webanwendungen kennt: Man klickt auf „Abmelden“, wird zurück zur Login-Seite geschickt, aber bei erneutem Klick auf die Anwendung ist man sofort wieder angemeldet, ohne Passwort. Technisch ist das kein Sicherheitsproblem, solange die Sitzung am IdP tatsächlich nach einer gewissen Zeit abläuft. Für den Nutzer ist es aber verwirrend, und in Umgebungen mit gemeinsam genutzten Rechnern kann es durchaus ein Sicherheitsrisiko darstellen.

Nextcloud unterstützt Single Logout über das SAML-Protokoll. Das setzt voraus, dass der IdP SLO kann und dass auf beiden Seiten die entsprechenden Endpunkte konfiguriert sind. ADFS zum Beispiel beherrscht SLO, Keycloak ebenfalls. In der Praxis scheitert SLO jedoch erstaunlich oft an kleinen Konfigurationsdetails, etwa daran, dass das Logout-Request-Binding nicht mit dem IdP-Ende übereinstimmt oder die Signaturen nicht validiert werden können. Nicht zuletzt deswegen haben viele Administratoren eine etwas angespannte Beziehung zu SLO. Meine Empfehlung: Erst die normale Authentifizierung sauber zum Laufen bringen, dann SLO in Angriff nehmen und ausgiebig testen. Ein SLO, das nur sporadisch funktioniert, ist schlimmer als gar keins.

Verschlüsselung, Signaturen und das leidige Thema Zertifikate

SAML-Assertions sind klassische XML-Dokumente, die signiert und optional auch verschlüsselt werden können. Signiert bedeutet: Der IdP weist nach, dass die Assertion wirklich von ihm stammt und nicht manipuliert wurde. Verschlüsselt bedeutet: Nur der Service Provider kann den Inhalt lesen. In der Praxis ist die Signatur Pflicht, die Verschlüsselung optional, aber dringend zu empfehlen, wenn die Assertion sensible Attribute wie E-Mail-Adressen oder Abteilungszugehörigkeiten enthält.

Das Problem an SAML ist, dass es den Umgang mit Zertifikaten nicht elegant gelöst hat. Es gibt keine zentrale Public-Key-Infrastruktur, sondern es werden einfach X.509-Zertifikate in den Metadaten ausgetauscht. Diese Zertifikate laufen ab. Und wenn sie ablaufen, ist die Anmeldung plötzlich nicht mehr möglich, was sich in der Praxis immer dann ereignet, wenn gerade niemand damit rechnet, etwa am ersten Montag nach den Betriebsferien. Ein Monitoring auf das Ablaufdatum der Metadaten ist daher kein Luxus, sondern eine notwendige Betriebsaufgabe. Nextcloud selbst warnt zwar, wenn das eigene Zertifikat abläuft, aber die Warnung geht im Log-Monitoring leicht unter.

Ein weiterer klassischer Fehler betrifft die Zertifikatskette. Manche IdPs senden ein Zertifikat, das von einer internen PKI ausgestellt wurde. Der Service Provider muss dieser PKI vertrauen, andernfalls schlägt die Validierung fehl. Während öffentliche Zertifikate oft ohne große Konfiguration funktionieren, erfordern interne Zertifikate das Hinterlegen der Root-CA. Auch hier gilt: Eine saubere Dokumentation der Zertifikatslandschaft ist das A und O. Genau daran mangelt es in vielen Unternehmen, die über Jahre hinweg eine SAML-Integration betreiben, ohne jemals einen Zertifikatswechsel durchgeführt zu haben.

Der Tanz der Bindings: POST, Redirect und Artifact

SAML kennt verschiedene Wege, wie die Nachrichten übertragen werden: über HTTP-Redirect, über HTTP-POST oder über den sperrigen Artifact-Binding. Nextcloud und die meisten IdPs verwenden üblicherweise Redirect für die Abfrage der Authentifizierung und POST für die Übermittlung der Assertion. Das ist in den Metadaten festgehalten, und man sollte nicht versuchen, daran herumzudoktern, wenn man nicht genau weiß, was man tut.

Interessant wird es, wenn Sicherheitsrichtlinien vorschreiben, dass die Assertion nicht über den Browser laufen darf, sondern über eine direkte Verbindung zwischen IdP und Service Provider. Dann kommt das Artifact-Binding zum Einsatz, das die eigentliche Assertion über einen separaten Kanal abruft. Das ist zwar sicherer, weil die Assertion nicht dem Browser ausgesetzt wird, aber es ist auch komplexer und wird in der Praxis eher selten genutzt. Für die meisten Nextcloud-Deployments reichen die Standard-Bindings völlig aus. Wichtig ist nur, dass beide Seiten dasselbe Binding erwarten. Eine häufige Fehlermeldung in diesem Zusammenhang ist, dass der IdP eine POST-Assertion an eine Stelle sendet, die nur Redirect erwartet – oder umgekehrt. Die Fehlermeldungen sind dann oft kryptisch und führen den Admin auf eine falsche Fährte. Es lohnt sich daher, bei Problemen zuerst einen Blick auf die Log-Dateien beider Systeme zu werfen, statt an der Konfiguration herumzudrehen.

Nextcloud-Konfiguration konkret: Ein Blick in die Praxis

Ein typisches Setup sieht folgendermaßen aus: Nextcloud ist bereits installiert, die SAML-App aktiviert. In config/config.php wird ein Abschnitt 'saml' => [...] angelegt, der die wichtigsten Parameter enthält: die ID des Service Providers, die URL des IdP, die Login- und Logout-Endpunkte, das öffentliche Zertifikat des IdP und die Optionen für das Attribut-Mapping. Diese Werte lassen sich mit Hilfe der occ-Befehle setzen, was sich besonders gut für automatisierte Deployments eignet. Ansible-Rollen, die Nextcloud samt SAML-Konfiguration ausrollen, sind in der Community weit verbreitet. Wer eine solche Automatisierung nutzt, sollte darauf achten, dass die SAML-Konfiguration nicht in der Datenbank, sondern in der Config-Datei liegt, damit sie versionierbar ist.

Danach muss der IdP die Nextcloud als vertrauenswürdigen Service Provider kennenlernen. Dazu importiert man die Nextcloud-Metadaten oder legt den Service Provider manuell an. Bei Keycloak genügt in der Regel der Upload der Metadaten-XML, anschließend werden die Endpunkte automatisch befüllt. Bei ADFS ist etwas mehr Handarbeit nötig, aber auch dort gibt es Assistenten, die einen durch den Prozess führen. Gerade bei ADFS ist es wichtig, die sogenannte „Identifier“-Eigenschaft korrekt zu setzen, also die EntityID der Nextcloud. Ein häufiger Fehler ist, dass hier die URL der Nextcloud-Instanz eingetragen wird, obwohl eine eigenständige ID, etwa https://cloud.example.com/apps/user_saml, erforderlich ist. Die Nextcloud-Metadaten geben die EntityID vor, und genau diese muss im IdP verwendet werden. Kleinigkeit, große Wirkung – und eine der häufigsten Fehlerquellen überhaupt.

Nach der Grundkonfiguration folgt der erste Login-Test. Am besten führt man diesen nicht als Administrator der Nextcloud durch, sondern mit einem Testnutzer aus dem IdP. Sonst passiert es leicht, dass der lokale Admin ausgesperrt wird und sich nicht mehr in die Nextcloud einloggen kann. Zwar kann man sich über die Konfigurationsdatei noch retten, indem man die SAML-Authentifizierung deaktiviert, aber das ist ein unnötiger Adrenalinmoment. Also: Erst einen Testnutzer anlegen, den SAML-Modus aktivieren, und dann Schritt für Schritt vorgehen.

Die Konfiguration des Attribut-Mappings erfolgt dann entweder über die Verwaltungsoberfläche oder über occ. Dabei ist die Zuordnung von uid, mail, displayname und groups das Minimum. Wichtig: Der Anzeigename in Nextcloud ist nicht zwingend derselbe wie im IdP. Man kann ihn über ein eigenes Attribut steuern, etwa cn oder displayName. Fehlt die Zuordnung, verwendet Nextcloud den Benutzernamen als Anzeigename, was bei manchen Nutzern auf Unverständnis stößt, weil dann statt des vollen Namens nur der Kürzel erscheint. Solche Details sollte man nicht unterschätzen, denn sie bestimmen maßgeblich die Akzeptanz der Anwendung.

Wenn der IdP nicht mitspielt: Typische Fehlerbilder und was sie bedeuten

Die häufigste Fehlermeldung in der Praxis ist eine schlichte „Anmeldung fehlgeschlagen“-Meldung in Nextcloud. Dahinter können viele Ursachen stecken. Ein Klassiker ist die Clock Skew: Der Server, auf dem Nextcloud läuft, und der Server des IdP weichen in ihrer Systemzeit ab. SAML-Validierungen prüfen die Gültigkeitsdauer der Assertion, und wenn die Serveruhren zu weit auseinanderliegen, gilt die Assertion als nicht gültig. Die Lösung ist einfach: NTP auf allen Servern, und zwar konsequent. Doch gerade in kleineren Umgebungen wird das vernachlässigt – bis der erste SAML-Login fehlschlägt.

Ein weiterer Klassiker ist das falsche Attribut für den Benutzernamen. Angenommen, der IdP sendet das Attribut mail, und Nextcloud ist auf uid konfiguriert. Dann passiert tatsächlich nichts Passendes – die Nextcloud meldet einen Fehler, der Nutzer wird nicht gefunden. In solchen Fällen hilft nur der Blick in die Logs. Die Nextcloud-Logdatei zeigt, welche Attribute in der Assertion angekommen sind, wenn man das Log-Level auf „debug“ setzt. Eine Einstellung, die man im Live-Betrieb natürlich nicht dauerhaft aktiviert haben sollte. Aber für die Fehlersuche ist sie Gold wert. Dabei zeigt sich übrigens immer wieder, dass die Probleme auf der IdP-Seite liegen, nicht auf der Nextcloud-Seite. Das ist keine Entschuldigung, sondern eine Beobachtung aus vielen Projekten.

Auch die Verwendung von unsignierten Assertions kommt gelegentlich vor, besonders in Testumgebungen. Nextcloud akzeptiert solche Assertions nur, wenn man die Sicherheitsprüfung explizit herunterstuft – was im Klartext bedeutet, dass man sich anfällig macht für Man-in-the-Middle-Angriffe. Davon kann man nur abraten, auch wenn es verlockend ist, die Konfiguration schnell zu testen. Besser ist es, von Anfang an mit signierten Assertions zu arbeiten, auch im Testbetrieb. So vermeidet man, dass später im Produktivbetrieb Sicherheitslücken entstehen, weil „es ja bisher auch funktioniert hat“.

Zwei Welten: SAML und lokale Konten parallel betreiben

Nicht jede Nextcloud-Installation kann von heute auf morgen vollständig auf SAML umgestellt werden. Es gibt immer wieder Sonderfälle: externe Berater, die nur temporär Zugriff benötigen, oder Systemaccounts, die keine eigene E-Mail-Adresse haben. Für solche Fälle erlaubt Nextcloud den parallelen Betrieb von SAML- und lokalen Konten. In der Konfiguration lässt sich einstellen, dass die normale Login-Seite weiterhin erreichbar bleibt und Nutzer wählen können, ob sie sich über SAML oder über lokale Zugangsdaten anmelden wollen.

Das klingt pragmatisch, ist aber aus Sicherheitsperspektive ein heikles Unterfangen. Jedes lokale Passwort ist ein potenzielles Einfallstor, wenn es schwache Passwörter gibt oder die Passwort-Richtlinien nicht konsequent durchgesetzt werden. Man sollte den Parallelbetrieb daher nur als Übergangslösung sehen, nicht als Dauerzustand. In manchen Unternehmen hat sich allerdings gezeigt, dass es durchaus legitim sein kann, lokale Konten für reine Funktionsbenutzer beizubehalten, beispielsweise für den Backup-Operator oder für den Notfall-Zugang des Administrators. Wichtig ist nur, dass diese Konten nicht mit hohen Rechten ausgestattet sind, es sei denn, es gibt keine Alternative. Und: Die lokalen Konten sollten nicht den gleichen Benutzernamen verwenden wie SAML-Konten. Sonst kann es zu Verwechslungen und im schlimmsten Fall zu einer Übernahme von Berechtigungen kommen, wenn sich ein SAML-Nutzer erfolgreich als lokaler Nutzer anmeldet, weil der Benutzername gleich ist. Das ist ein subtiles Risiko, das viele übersehen.

Der Betrieb danach: Monitoring, Logging und die Frage, wer bei Störungen hilft

Ist die SAML-Anbindung erst einmal eingerichtet, beginnt der eigentliche Alltag. Und der besteht leider nicht nur aus glücklichen Anwendern, die sich nahtlos in ihre Cloud einloggen. Er besteht auch aus Fehlermeldungen, aus ablaufenden Zertifikaten, aus IdP-Wartungen, aus Änderungen an den Attributnamen, die der IdP-Administrator irgendwann einmal vornimmt, ohne die Auswirkungen auf andere Systeme zu bedenken. Wer SAML einführt, muss sich darüber im Klaren sein, dass er damit eine zusätzliche Abhängigkeit schafft: Wenn der IdP nicht erreichbar ist, dann ist auch die Nextcloud nicht mehr nutzbar – zumindest für jene Nutzer, die ausschließlich über SAML kommen. Eine lokale Notfall-Authentifizierung für den Admin ist deshalb keine Kür, sondern eine Pflichtübung.

Bei der Überwachung hilft es, die Nextcloud-Logs zu überwachen und sich bei wiederkehrenden SAML-Fehlern automatisierte Warnungen schicken zu lassen. Das lässt sich mit den üblichen Monitoring-Werkzeugen wie Prometheus oder Icinga umsetzen. Aber auch ein simpler Cronjob, der die Logdatei nach dem Stichwort „SAML“ durchsucht, kann schon Wunder wirken. Oft sind es nämlich nicht die spektakulären Angriffe, die Probleme machen, sondern die stillen Fehler, die im Log stehen, ohne dass jemand hinschaut. Ein Beispiel: Ein IdP beginnt, den Attributnamen für den Anzeigenamen leicht zu verändern (weil die IdP-Software aktualisiert wurde). Plötzlich stimmt das Mapping nicht mehr, und alle Nutzer sehen in Nextcloud nur noch ihren Benutzernamen statt des vollständigen Namens. Kein Sicherheitsproblem, aber eine spürbare Verschlechterung der Benutzerfreundlichkeit, die sich erst nach Tagen bemerkbar macht, weil niemand das Log liest.

Hinzu kommt die Verantwortungsfrage: Wer betreibt den IdP? Ist es die eigene IT-Abteilung, kann man schnell kommunizieren. Ist es eine externe Instanz, etwa ein Identity-Provider-as-a-Service, dann muss man wissen, wie die Eskalationswege funktionieren. Viele Unternehmen haben hierüber keine klaren Vereinbarungen. Wenn dann um 20 Uhr abends die Anmeldung klemmt, steht der Nextcloud-Administrator allein da und versucht, eine Lösung zu finden, die eigentlich auf einer anderen Seite liegen müsste. Solche Situationen lassen sich nur durch ein gutes Betriebskonzept vermeiden, das die Zuständigkeiten und Schnittstellen beschreibt.

SAML versus OpenID Connect: Wie Nextcloud beide Welten bedient

Es wäre untertrieben, zu behaupten, dass SAML die einzige moderne Methode für die Authentifizierung sei. In den letzten Jahren hat OpenID Connect, kurz OIDC, stark an Boden gewonnen. OIDC ist schlanker, basiert auf JSON statt auf XML und ist im Web-Umfeld oft einfacher zu implementieren. Auch Nextcloud unterstützt OIDC über eine eigene App, wobei die Verbreitung und der Reifegrad der SAML-Integration in der Praxis höher sind. Das liegt nicht an der Technologie, sondern an der historischen Entwicklung: Nextcloud ist aus ownCloud hervorgegangen, und ownCloud hatte sich früh auf SAML konzentriert, weil die ersten großen Kunden aus dem Hochschul- und Behördenumfeld kamen, wo SAML als Standard etabliert ist. Diese DNA steckt bis heute in der Plattform.

Für IT-Verantwortliche stellt sich daher die Frage, ob sie bei der Einführung auf SAML oder OIDC setzen sollen. Die Antwort hängt stark von der bestehenden Infrastruktur ab. Wer bereits einen ADFS- oder Shibboleth-Verbund betreibt, sollte auf SAML gehen, weil es dort nahtlos integriert ist. Wer von einer modernen Cloud-Plattform wie Entra ID (ehemals Azure AD) spricht, der findet zwar auch SAML, aber OIDC ist dort oft der elegantere Weg, gerade wenn die Nextcloud nur eine von mehreren Anwendungen ist, die angebunden werden sollen. Es geht also nicht darum, welches Protokoll das bessere ist, sondern darum, welches im jeweiligen Ökosystem besser passt. Nextcloud lässt einem hier die Wahl, was zweifellos eine Stärke ist.

Ein interessanter Aspekt ist übrigens die Kombination beider Verfahren. Es ist möglich, in derselben Nextcloud-Instanz verschiedene IdPs zu betreiben, einen per SAML und einen per OIDC. Das ist allerdings eine Konfiguration, die man nicht nebenbei aufsetzt. Sie erfordert ein gutes Verständnis der jeweiligen Protokolle und der Risiken. Vor allem sollte man sich bewusst machen, dass jede zusätzliche Authentifizierungsmöglichkeit die Angriffsfläche vergrößert. Die Devise „so viel wie nötig, so wenig wie möglich“ gilt hier mehr denn je.

Nextcloud und der Identity Provider: Der Schlüssel liegt in der Datenpflege

Viele Administratoren unterschätzen, dass SAML nicht nur ein technisches Konstrukt ist, sondern vor allem ein Datenmodell. Der IdP liefert Attribute, die in der Nextcloud interpretiert werden. Diese Attribute müssen gepflegt sein, und zwar sorgfältig. Dazu gehört, dass der Benutzername wirklich eindeutig ist, dass E-Mail-Adressen nicht doppelt vergeben sind und dass Gruppen eine saubere Hierarchie haben. In der Praxis sieht man häufig, dass Attribute historisch gewachsen sind und ihre Bedeutung sich im Laufe der Zeit verschoben hat. Ein Attribut namens employeeType, das früher einmal die Abteilung beschrieb, wird heute für völlig andere Zwecke verwendet. Wenn dann jemand darauf ein SAML-Mapping aufbaut, entsteht eine Dynamik, die niemand wirklich versteht.

Die Verantwortung für die Datenqualität liegt nicht beim Nextcloud-Administrator, sondern beim Identity-Management. Wer keine Governance für seine Identitätsdaten etabliert hat, wird mit SAML nicht glücklich. SAML verstärkt die Probleme, die in den Quelldaten existieren. Es ist wie bei einer Trinkwasserleitung: Wenn der Brunnen verschmutzt ist, hilft der beste Wasserfilter nichts. In der Beratungspraxis begegnet man deshalb immer wieder Unternehmen, die SAML als Allheilmittel betrachten, obwohl das eigentliche Problem in den ungepflegten Active-Directory-Attributen liegt. Der IdP gibt nur weiter, was er bekommt. Und wenn dort schon Unsinn steht, steht später in der Nextcloud der gleiche Unsinn.

Der Blick in die Glaskugel: Wohin entwickelt sich die Authentifizierung?

Es wäre vermessen, eine Prognose über die Zukunft von SAML zu wagen, ohne den Kontext zu betrachten. Sicher ist, dass SAML auch in den kommenden Jahren eine wichtige Rolle spielen wird, gerade im Enterprise-Umfeld und im öffentlichen Sektor. Die Installationsbasis ist zu groß, als dass sie über Nacht abgelöst würde. Gleichzeitig zeigt sich, dass die Weiterentwicklungen im Bereich der passwortlosen Authentifizierung, also etwa WebAuthn und Passkeys, an SAML nicht spurlos vorbeigehen. Diese Verfahren arbeiten häufig als zusätzlicher Faktor innerhalb der Authentifizierungskette, die nach wie vor über den IdP läuft. Der IdP bleibt also der zentrale Knotenpunkt, SAML bleibt das Transportprotokoll.

Interessant wird es, wenn man die Entwicklungen im Föderationsbereich betrachtet. Hochschulen, Forschungseinrichtungen und Behörden tauschen längst nicht mehr nur einfache Attribut-Listen aus, sondern verhandeln feingranulare Autorisierungsentscheidungen. SAML ist dafür eigentlich zu statisch. OpenID Connect und das benachbarte OAuth-2.0-Framework bieten hier mehr Flexibilität, insbesondere wenn es um die Delegation von Zugriffsrechten geht. In der Nextcloud-Community wird dieses Thema bereits diskutiert, und es gibt erste Ansätze, die über reine Authentifizierung hinausgehen. Dateien aus einer Nextcloud in eine andere zu verschieben, ohne die Konten zusammenzuführen – das wäre ein Szenario, das mit moderneren Identitätsprotokollen attraktiver wird.

Bis es so weit ist, gilt: Nextcloud mit SAML zu betreiben ist ein solides Handwerk. Es erfordert Sorgfalt, ein gutes Verständnis der Grundlagen und eine gehörige Portion Geduld. Wer diesen Aufwand scheut, wird mit den Symptomen kämpfen, statt die Ursachen zu beheben. Und wer das Thema ernst nimmt, der wird mit einer Lösung belohnt, die im IT-Alltag tatsächlich Zeit spart und die Sicherheit erhöht – nicht zuletzt, weil die Passwortproblematik aus der Anwendung verschwindet und dorthin verlagert wird, wo sie hingehört: in eine zentrale, gut überwachte Instanz.

Praktische Empfehlungen zum Schluss

Was also bleibt, wenn man sich durch die Weiten der SAML-Dokumentationen gearbeitet hat? Eine Reihe von offensichtlichen, aber gerne ignorierten Wahrheiten. Erstens: Man sollte SAML nicht einführen, während man noch mitten in der Nextcloud-Migration steckt. Erst die Migration abschließen, dann die Authentifizierung umstellen – oder umgekehrt, aber niemals beides gleichzeitig. Zweitens: Die Testphase ist kein Übel, sondern die wichtigste Investition. Sie muss ein breites Spektrum realer Szenarien abdecken: Anmeldung mit gültigen und ungültigen Zertifikaten, Ablauf der Sitzung, Gruppenwechsel, Passwortänderung im IdP, temporäre Sperre des Kontos, Nicht-Erreichbarkeit des IdP. Und drittens: Man sollte die SAML-Konfiguration dokumentieren, und zwar so, dass auch ein Kollege, der die SAML-Welt noch nie gesehen hat, nachvollziehen kann, warum welche Einstellung gewählt wurde. Diese Dokumentation fehlt in erstaunlich vielen Unternehmen – bis zu dem Tag, an dem der letzte Eingeweihte das Unternehmen verlässt und die SAML-Konfiguration zu einem digitalen Rätsel wird.

Wer diese Punkte ernst nimmt, der wird mit Nextcloud und SAML keine abenteuerliche Reise erleben, sondern eine langweilige, unaufgeregte und zuverlässige Zusammenarbeit. Und genau das ist im IT-Betrieb ja das eigentliche Ziel: nicht Spannung und Nervenkitzel, sondern Vorhersehbarkeit und Vertrauen. Die Nextcloud, die sich nahtlos in den bestehenden Identitätsverbund einfügt und auf die sich alle Nutzer, vom Vorstand bis zum Praktikanten, ohne Zögern einloggen, ist am Ende die eigentliche Rechtfertigung für die Mühen der Integration.

In diesem Sinne: SAML ist keine alte Technologie, die man nur noch mit angehaltenem Atem betreibt. SAML ist ein bewährtes Werkzeug, das in der richtigen Umgebung glänzt. Und Nextcloud bietet eine der reifsten und am besten durchdachten Integrationen dieses Werkzeugs in eine Open-Source-Kollaborationsplattform – genug Stoff für die nächste Diskussion in der IT-Abteilung, vielleicht beim nächsten Wartungsfenster, wenn alle Systeme wieder laufen und der Feierabend in greifbarer Nähe ist.