SSO-Offboarding: Anbieter über den Login hinaus prüfen

Eine Checkliste für das SSO-Offboarding prüft, was passiert, nachdem Sie einer Person beim Identitätsanbieter den Zugriff entzogen haben. Testen Sie neue Anmeldungen, laufende Sitzungen, API-Tokens, verbundene Assistenten und manuell eingeladene Mitglieder. Halten Sie fest, wann der Zugriff auf den Arbeitsbereich tatsächlich endet, welche Ausnahmen bleiben und wer den Zugang sperren kann, wenn der Verzeichnisabgleich ausfällt.

Bei Ihrer Produktvorführung zeigt der Anbieter vermutlich eine erfolgreiche Anmeldung. Lassen Sie sich auch den Austritt vorführen. In einem Bewerbermanagementsystem mit Kandidatendaten, Interviewnotizen und internen Teamgesprächen gehören beide Abläufe zur Kaufentscheidung.

Warum sollten Sie das Offboarding bei der SSO-Auswahl prüfen?

Eine erfolgreiche Single-Sign-on-Vorführung zeigt, dass die Anmeldung funktioniert. Sie zeigt nicht, was beim Ausscheiden einer Person mit bereits bestehenden Zugängen passiert.

Die aktuelle SAML-Debatte bietet einen Anlass, diese Frage jetzt zu stellen. In seinem Artikel vom 21. September, SAML: Ein Protokoll voller Designprobleme, kritisiert Matt Schwager von Trail of Bits die Komplexität von SAML und empfiehlt den Wechsel zu OpenID Connect. Die Diskussion auf Hacker News rückt diese Protokollentscheidung für Softwareteams wieder in den Vordergrund.

Das ist ein Grund, die Identitätsverwaltung Ihres Anbieters genauer zu prüfen. Es belegt weder, dass jede SAML-Installation kompromittiert ist, noch, dass mit OpenID Connect das Offboarding erledigt wäre. Für Ihre Kaufentscheidung zählt mehr als das Protokoll auf der Anmeldeseite.

Stellen Sie sich vor, ein Recruiter verlässt Ihr Unternehmen. Sein Konto wird in Ihrem Verzeichnis deaktiviert. Er hat aber noch einen ATS-Tab geöffnet, ein Token für ein Auswertungsskript und einen Assistenten, der mit dem Recruiting-Arbeitsbereich verbunden ist. Eine neue Anmeldung kann bereits scheitern, während diese anderen Zugänge gesondert gesperrt werden müssen.

Verstehen Sie dieses Beispiel als Testszenario, nicht als Behauptung über ein bestimmtes Produkt. Lassen Sie den Anbieter zeigen, wie sich seine konkrete Konfiguration verhält. Beziehen Sie die Verantwortlichen für Recruiting-Zugänge und die Person ein, die bei einem fehlgeschlagenen Abgleich benachrichtigt wird. Überlassen Sie die Prüfung nicht allein der Person, die SSO eingerichtet hat.

Am Ende sollte ein kurzes Abnahmeprotokoll stehen: welche Zugänge Sie geprüft haben, welches Ergebnis Sie erwartet und beobachtet haben und welche Ausnahmen Sie akzeptieren. Damit haben Einkauf und spätere Offboarding-Verantwortliche eine präzisere Grundlage als den Vermerk „SSO wird unterstützt“.

Trennen Sie Anmeldung, Bereitstellung und Anwendungszugriff

Authentifizierung, Mitgliederverwaltung und Zugriffsentzug beantworten unterschiedliche Fragen. Klären Sie, wie der Anbieter diese Funktionen in Ihrer geplanten Konfiguration verbindet.

OpenID Connect Core beschreibt die Authentifizierung auf Basis von OAuth 2.0 sowie Angaben zur Identität des Nutzers. Damit ist noch kein vollständiger Austrittsprozess für Ihr Unternehmen festgelegt.

Microsofts Anleitung zum Zugriffsentzug verdeutlicht die Zuständigkeit der Anwendung. Sie kann ein eigenes Sitzungstoken ausstellen und die Autorisierung selbst steuern. Die Deaktivierung einer Identität in Microsoft Entra gibt Entra keine direkte Kontrolle über dieses Anwendungstoken. Ob bestehender Zugriff erhalten bleibt, hängt vom Verhalten und der Konfiguration der Anwendung ab.

Prüfen Sie die Bereitstellung genauso genau. SCIM, ein Standard zum Austausch von Informationen für die Identitätsverwaltung, enthält das Attribut active. Dessen genaue Bedeutung überlässt das Kernschema dem Dienstanbieter. Eine erfolgreich verarbeitete Anfrage mit active=false beweist für sich genommen nicht, dass sämtliche Zugangsmittel der Anwendung unwirksam geworden sind.

Auch eine Abmeldung hat einen begrenzten Geltungsbereich. Die gesonderte Spezifikation für OpenID Connect Back-Channel Logout beschreibt, wie Anwendungen benachrichtigt werden, damit sie die zugehörigen Sitzungen beenden. Die Unterstützung ist optional. Refresh-Tokens mit Offline-Zugriff behandelt die Spezifikation im Regelfall anders als sitzungsgebundene Refresh-Tokens. Setzen Sie „unterstützt Abmeldung“ deshalb nicht mit „widerruft sämtliche Zugangsmittel“ gleich.

Für diese Prüfung müssen Sie kein Protokoll implementieren können. Lassen Sie sich jede Tabellenzeile verständlich erklären und die wichtigen Zugangswege vorführen. Eine klare Antwort nennt den Auslöser, die betroffenen Identitätstypen, die erwartete Verzögerung und die Ausnahmen.

Vereinbaren Sie Auslöser und Frist für den Zugriffsentzug

Ein Offboarding-Test braucht ein klar definiertes Ausgangsereignis und einen eindeutig abgegrenzten Zugriffsbereich. Sonst können Käufer und Anbieter dieselbe Vorführung sehen und trotzdem unterschiedlicher Meinung darüber sein, was bestanden wurde.

Notieren Sie zuerst die Konfiguration: Produkttarif, Identitätsanbieter, verpflichtendes SSO, Bereitstellungsverbindung und die Herkunft der Testmitgliedschaft. Für einen manuell eingeladenen Gast kann ein anderer Entzugsweg gelten als für einen Mitarbeiter, dessen Mitgliedschaft über das Verzeichnis angelegt wurde. Testen Sie die Konfiguration, mit der Sie später tatsächlich arbeiten werden.

Legen Sie dann den Auslöser fest. Einen Verzeichnisnutzer zu deaktivieren, eine Anwendungszuweisung aufzuheben, eine Gruppenmitgliedschaft zu entfernen oder eine lokale Mitgliedschaft im Arbeitsbereich zu löschen, sind unterschiedliche Aktionen. Testen Sie die Aktion, die Ihr Austrittsprozess vorsieht. Ergänzen Sie gesonderte Tests, wenn Ihr Betrieb auf weitere Auslöser angewiesen ist.

Vereinbaren Sie für jeden wichtigen Zugangsweg eine akzeptable Höchstfrist. Das ist Ihr Abnahmekriterium, keine allgemeingültige Branchen-SLA. Fragen Sie den Anbieter, was er zusichert, was er lediglich zeitlich einplant und was Verantwortliche tun sollen, wenn der normale Ablauf scheitert.

Beispielsweise können Sie verlangen, dass eine zuständige Person im Notfall den Zugang direkt in der Anwendung entzieht, statt auf den nächsten geplanten Abgleich zu warten. Halten Sie dieses Vorgehen mit Zuständigkeit und erforderlichen Berechtigungen fest. Gehen Sie nicht davon aus, dass es bereits möglich ist, nur weil Administratoren normalerweise Nutzer bearbeiten können.

Erfassen Sie drei Zeitpunkte getrennt: die Aktion im Verzeichnis, ihren Empfang oder ihre Verarbeitung durch die Anwendung und die Ablehnung einer geschützten Anfrage. Eine Erfolgsmeldung des Konnektors ist ein nützlicher Zustellnachweis. Sie ist aber nicht derselbe Nachweis wie ein gescheiterter Versuch, einen geschützten Datensatz abzurufen.

Klären Sie schließlich, was „Zugriff entzogen“ bedeutet. Wer Ihren Unternehmensarbeitsbereich nicht mehr öffnen darf, muss deshalb nicht auch einen unabhängigen persönlichen Arbeitsbereich verlieren oder überall beim Anbieter abgemeldet werden. Umgekehrt reicht eine Weiterleitung im Browser nicht aus, wenn ein Token derselben Person weiterhin Ihre Kandidatendaten lesen kann.

Führen Sie diesen Abnahmetest für das SSO-Offboarding durch

Verwenden Sie eine eigens angelegte Testidentität und künstliche Datensätze in einem vom Anbieter freigegebenen Testarbeitsbereich. Prüfen Sie vor dem Zugriffsentzug, ob der Zugang funktioniert, und wiederholen Sie danach dieselben unkritischen Vorgänge.

Halten Sie einen weiteren Administrator bereit, der die Konfiguration wiederherstellen kann. Nutzen Sie weder das echte Konto eines Mitarbeiters noch reale Kandidatendaten für die Vorführung. Die folgende Vorlage ist unser Vorschlag für den Testaufbau, keine Zertifizierung und kein von Kit erzeugter Prüfbericht.

Prüfen Sie zunächst den Ausgangszustand

Legen Sie einen fiktiven Kandidaten oder einen anderen unkritischen geschützten Datensatz an. Vergewissern Sie sich, dass das Testmitglied ihn über jeden unterstützten Zugangsweg lesen kann, den Sie prüfen möchten. Hat ein Vorgang schon vor dem Zugriffsentzug nicht funktioniert, sagt sein späteres Scheitern nichts über den Widerruf aus.

Nutzen Sie getrennte Browser für Testmitglied und Administrator. Dokumentieren Sie Rolle, Herkunft der Mitgliedschaft und relevante Gruppenzuweisungen. Erfassen Sie die angelegten Zugangsmittel, ohne ihre geheimen Werte in das Prüfprotokoll zu kopieren.

Führen Sie dann die vereinbarte Aktion zum Zugriffsentzug aus und notieren Sie den Zeitpunkt. Lassen Sie die bestehende Browsersitzung geöffnet. Mit einem neuen Browser allein würden Sie genau das Verhalten übersehen, das Sie prüfen müssen.

Wiederholen Sie die relevanten Zugriffe

Lassen Sie bei OAuth-Clients zwischen dem Token für Ressourcenanfragen und einem etwaigen Refresh-Token zur Erneuerung unterscheiden. RFC 7009 definiert den Token-Widerruf gesondert und behandelt seine Auswirkungen auf zugehörige Tokens. Im Abnahmeprotokoll sollte stehen, welche Zugangsmittel Sie getestet haben, nicht nur „OAuth geprüft“.

Verwechseln Sie eine alte Seitenansicht nicht mit fortbestehendem Zugriff. Bereits angezeigter Text kann im Tab sichtbar bleiben, obwohl die Berechtigung erloschen ist. Fordern Sie geschützte Inhalte erneut an und prüfen Sie, ob der Server sie zurückgibt. Akzeptieren Sie umgekehrt keine bloß optische Meldung „abgemeldet“, wenn geschützte Anfragen weiterhin erfolgreich sind.

Dokumentieren Sie Nachweise, die andere nachvollziehen können

Notieren Sie für jeden Zugangsweg die letzte beobachtete erfolgreiche und die erste beobachtete abgewiesene Anfrage. Diese Prüfungen grenzen den beobachteten Zeitraum ein. Sie bestimmen nicht den exakten Zeitpunkt dazwischen, zu dem der Zugriff endete. Ein einzelner erfolgreicher Durchlauf belegt auch nicht die längstmögliche Verzögerung des Anbieters.

Diese Felder genügen für ein kompaktes Protokoll:

Speichern Sie weder Tokens noch vertrauliche Antwortinhalte im Protokoll. Eine berechtigte prüfende Person braucht genügend Nachweise, um die Schlussfolgerung nachzuvollziehen – keine neue Sammlung von Zugangsmitteln oder Kandidatendaten.

Scheitert ein Prüfschritt, benennen Sie den weiterhin möglichen Vorgang. „Der bereits geöffnete Browser kann nach Ablauf der vereinbarten Frist neu angelegte Kandidatennotizen lesen“ ist hilfreicher als „SSO funktioniert nicht“. Damit zeigen Sie dem Anbieter, welchen Zugriff er tatsächlich unterbinden muss.

Halten Sie Ausnahmen vor der Anbieterabnahme fest

Ausnahmen und der Umgang mit Fehlern gehören zur Abnahmeentscheidung. Ein erfolgreicher Test mit einem über das Verzeichnis verwalteten Mitarbeiter deckt nicht alle Personen, Zugangsmittel oder Ausfälle ab.

Beginnen Sie mit der Herkunft der Mitgliedschaft. Oktas Dokumentation zur Deaktivierung beschreibt Voraussetzungen und Ausnahmen für den automatischen Zugriffsentzug in Anwendungen. Daraus ergibt sich eine praktische Frage für die Anbieterauswahl: Welche Anwendungen und Identitäten verwaltet Ihre konkrete Verbindung tatsächlich?

Listen Sie manuell eingeladene Mitglieder, externe Mitwirkende, Dienstkonten und Notfalladministratoren auf, soweit vorhanden. Ordnen Sie jedem Typ einen Entzugsweg und eine zuständige Person zu. Lassen Sie ein bewusst eingerichtetes Notfallkonto nicht zur unsichtbaren Ausnahme werden. Dokumentieren Sie, wer es verwaltet und wie seine Nutzung überprüft wird.

Prüfen Sie Ausfall und Wiederherstellung gezielt

Fragen Sie, wie die zuständige Person erfährt, dass der Verzeichnisabgleich ausgefallen ist oder eine Änderung zurückgewiesen hat. Ein Zeitstempel von gestern kann aussagekräftiger sein als eine grüne Anzeige „verbunden“. Bitten Sie um eine vom Anbieter unterstützte Fehlersimulation. Ist das nicht sicher möglich, prüfen Sie dokumentierte Nachweise eines solchen Fehlers.

Führen Sie das manuelle Ersatzverfahren durch und wiederholen Sie die relevanten Zugriffstests. Ein Ersatzverfahren hilft nur, wenn die benannte Person es auch bei ausgefallener Integration ausführen kann. Klären Sie die nötigen Administratorrechte und den Ablageort der Anleitung.

Testen Sie außerdem eine Herabstufung der Rolle und einen Wiedereintritt als getrennte Szenarien. Prüfen Sie nach der Herabstufung den geschützten Vorgang, den die Person nicht mehr ausführen dürfen soll. Vergleichen Sie nach dem Wiedereintritt die Berechtigungen mit der neu genehmigten Rolle. Setzen Sie weder die automatische Wiederherstellung alter Rechte noch den dauerhaften Verlust sämtlicher Zugänge voraus.

Grenzen Sie Ihre Entscheidung klar ab

Lassen Sie sich die Erklärung des Anbieters schriftlich geben und legen Sie sie zur Konfiguration und den beobachteten Ergebnissen. Unterscheiden Sie zwischen Produktfunktion, vertraglicher Zusage und gemessenem Testergebnis. Betrifft eine ungeklärte Ausnahme sensible Kandidatendaten, entscheiden Sie: Konfiguration ändern, eine praktikable zusätzliche Kontrolle einführen oder die Abnahme verschieben.

Wer die nächste Anfrage verweigert, holt damit keine bereits kopierten Informationen zurück. Behandeln Sie heruntergeladene Dateien, Exporte und aufbewahrte Kopien als eigenständige Aufgabe der Datenverwaltung. Konzentrieren Sie diese Prüfung darauf, weiteren Zugriff auf den Arbeitsbereich zu verhindern.

Der Umgang mit Nachweisen ähnelt dem Abschluss einer Meldung zu offengelegten Zugangsdaten: Benennen Sie den betroffenen Zugangsweg und prüfen Sie das Ergebnis. Hier geht es jedoch um einen geplanten Austritt und die Anbieterabnahme, nicht um die Reaktion auf einen Sicherheitsvorfall.

Wenden Sie dieselbe Checkliste auf Kit an

Prüfen Sie das Produkt in der Konfiguration, die Sie tatsächlich einsetzen werden, einschließlich ihrer Grenzen. Lassen Sie Kit denselben Austrittstest durchlaufen, den Sie auch von anderen Anbietern verlangen würden.

Kit unterstützt SAML Single Sign-on und eine separate Verbindung zum Verzeichnisabgleich mit Google Workspace. Die Integration fragt Google regelmäßig ab; sie ist kein allgemeiner SCIM-Endpunkt. Der Abgleich ist stündlich eingeplant, und auf der Verzeichnisseite gibt es Jetzt synchronisieren. Ein Zeitplan garantiert keine Frist für den Zugriffsentzug: Fehler beim externen Dienst, verzögerte Hintergrundaufträge und Schutzmechanismen können einen erfolgreichen Durchlauf verhindern.

Die Verbindung verwaltet nur Mitgliedschaften, die sie selbst angelegt hat. Sie entfernt weder den Kontoinhaber noch manuell eingeladene Mitglieder. Wird die Synchronisierung getrennt, enden künftige Abgleiche; bestehende Mitglieder bleiben erhalten. Tragen Sie diese Grenzen vor dem Test in Ihr Protokoll ein. Die Dokumentation zu SSO und Verzeichnisbereitstellung beschreibt Einrichtung und unterstütztes Verhalten.

Zusätzlich gibt es einen bewussten Schutz vor Massenentfernungen. Würde ein Abgleich sämtliche über das Verzeichnis verwalteten Mitglieder entfernen, wird er gestoppt – auch dann, wenn diese Gruppe nur eine Person umfasst. Bei mindestens vier verwalteten Mitgliedern wird auch die Entfernung von mehr als der Hälfte gestoppt. Berechtigte Austritte, die dieser Schutz erfasst, erfordern eine Prüfung durch Verantwortliche und die manuelle Entfernung.

Wird eine Mitgliedschaft durch den Verzeichnisabgleich erfolgreich gelöscht, entfernt Kits Implementierung die API-Tokens dieses Nutzers für das Konto, widerruft kontogebundene OAuth/MCP-Zugangsmittel und trennt dessen Live-Verbindungen zu diesem Konto. Das betrifft den Arbeitsbereich, aus dem die Person entfernt wurde. Es löscht weder ihre globale Nutzeridentität noch verspricht es eine Abmeldung aus allen anderen Arbeitsbereichen.

Für manuelle Austritte dokumentiert die Team-Zugriffssteuerung Aus Konto entfernen und die Prüfung bestehender Rechte. Bei geschützten Aufgaben mit nur einer verantwortlichen Person wählen Sie vor der Entfernung einen Nachfolger oder lassen die Aufgabe ausdrücklich unzugewiesen. Der Kontoinhaber bleibt vor Entfernung geschützt; auch bei verpflichtendem SSO behält er einen Notfallzugang. Prüfen Sie diese Ausnahme zusammen mit Ihren Einstellungen zur Anmeldesicherheit.

Das sind dokumentierte und anhand des Quellcodes geprüfte Verhaltensweisen. Dieser Artikel behauptet nicht, einen praktischen Abnahmetest Ihrer Installation durchgeführt zu haben. Prüfen Sie weiterhin alle für Sie relevanten Zeilen, einschließlich manueller Mitglieder und ausgefallener Synchronisierung.

Zu einer fundierten SSO-Entscheidung gehören ein nachgewiesener Entzugsweg, dokumentierte Zeitverläufe und eine Person, die Ausnahmen bearbeiten kann. Nutzen Sie die Vorlage beim Test von Kit oder im nächsten Anbietergespräch. Prüfen Sie den Austritt genauso sorgfältig wie die Anmeldung.