Single Sign-on erleichtert die Anmeldung an mehreren Anwendungen. Beschäftigte authentisieren sich bei einem zentralen Identitätsdienst; angebundene Anwendungen vertrauen anschließend einer geprüften Identitätsaussage. Das kann verteilte Passwörter und unübersichtliche Konten reduzieren. Gleichzeitig wird der zentrale Dienst zu einem besonders wichtigen Angriffsziel und erhält Einblick in Anmeldevorgänge.
Für Datenschutz und Sicherheit genügt deshalb die Aussage „Wir haben SSO“ nicht. Entscheidend sind die tatsächlich übertragenen Attribute, die Berechtigungen innerhalb der Anwendungen, der Umgang mit bestehenden Sitzungen und die Wiederherstellung nach einem Ausfall. Dieser Leitfaden führt von der Funktionsweise zu einer ausgefüllten Freigabematrix für einen beispielhaften Betrieb.
1. Was Single Sign-on technisch bedeutet
Drei Beteiligte müssen auseinandergehalten werden: die Person mit ihrem Browser oder Gerät, der Identitätsdienst und die Anwendung. Die Anwendung leitet eine Anmeldung an den Identitätsdienst weiter. Nach erfolgreicher Prüfung erhält sie eine für diesen Vorgang bestimmte Antwort und eröffnet gegebenenfalls eine eigene Sitzung.
OpenID Connect ergänzt OAuth 2.0 um eine standardisierte Authentisierung. OAuth allein beschreibt die delegierte Autorisierung und ist nicht automatisch ein belastbares Anmeldeverfahren. Ein ID Token enthält Angaben über die Authentisierung; ein Access Token dient dem Zugriff auf eine Ressource. Diese Funktionen sollten auch in Architekturzeichnungen getrennt bleiben. Das beschreibt die OpenID-Connect-Kernspezifikation.
Eine bestehende zentrale Sitzung kann weitere Anmeldungen erleichtern. Trotzdem entstehen häufig zusätzliche Anwendungssitzungen. SSO bedeutet daher weder ein einziges universelles Sitzungscookie noch automatisch dieselben Zugriffsrechte in allen Anwendungen. Auch SAML-basierte Anbindungen und ältere lokale Konten können parallel existieren. Tragen Sie diese Unterschiede bei der Kartierung der IT-Systemlandschaft ausdrücklich ein.
2. Vorteile und neue Abhängigkeiten abwägen
Eine zentrale Anmeldung kann die Einführung starker Authentisierung vereinfachen. Die IT muss weniger einzelne Passwortverfahren betreiben und kann Konten an einer zentralen Stelle sperren. Beschäftigte müssen nicht für jede angebundene Anwendung ein weiteres Geheimnis verwalten. Einheitliche Freigabeprozesse lassen sich leichter nachvollziehen.
Diese Vorteile entstehen nur bei vollständiger Anbindung. Bleibt ein altes lokales Administratorkonto aktiv, kann es die zentrale Sperre umgehen. Werden ausgeschiedene Personen lediglich aus dem Verzeichnis entfernt, können noch gültige Anwendungssitzungen oder technische Zugangsschlüssel fortbestehen. Ein Anbieterlogo im Anmeldefenster sagt darüber wenig aus.
Die Konzentration erhöht zugleich die Bedeutung eines kompromittierten Identitätsdienstes. Ein Angreifer mit weitreichenden Administrationsrechten könnte neue Vertrauensbeziehungen einrichten oder Authentisierungsregeln abschwächen. Ein Ausfall kann zahlreiche Fachprozesse gleichzeitig beeinträchtigen. Die Bewertung muss deshalb Vertraulichkeit, Integrität und Verfügbarkeit gemeinsam erfassen; Artikel 32 DSGVO verlangt eine dem Risiko angemessene Sicherheit und die regelmäßige Bewertung der Wirksamkeit. Eine bestimmte SSO-Marke schreibt die Vorschrift nicht vor.
3. Welche Identitätsdaten benötigt jede Anwendung?
Erstellen Sie für jede Anbindung eine Liste der tatsächlich übermittelten Attribute. Häufig gehören dazu eine Kontokennung, ein Anzeigename, eine E-Mail-Adresse oder eine Gruppenmitgliedschaft. Nicht jede Anwendung benötigt das komplette Unternehmensprofil. Ein internes Schulungsportal braucht beispielsweise nicht automatisch private Telefonnummer, Geburtsdatum und sämtliche Organisationsgruppen.
Prüfen Sie auch indirekte Informationen. Eine Gruppe mit der Bezeichnung „Betriebsratsmitglieder“ oder ein aussagekräftiger Abteilungsname kann mehr offenlegen als eine neutrale Anwendungsrolle. Die technische Bequemlichkeit eines vollständigen Gruppenexports rechtfertigt dessen Umfang nicht. Die Prüfung einzelner Felder auf Datenminimierung lässt sich auf diese Attribute übertragen.
OpenID Connect unterscheidet öffentliche und paarweise Kennungen. Bei paarweisen Kennungen wird der Wert anhand eines Sektoridentifikators gebildet; gemeinsam verwaltete Anwendungen können deshalb innerhalb eines Sektors dieselbe Kennung erhalten. Die Konfiguration kann unerwünschte Verknüpfungen zwischen anderen Anwendungen erschweren. Sie erzeugt aber keine anonyme Nutzung gegenüber einem Identitätsdienst, der die Zuordnung kennt. Dokumentieren Sie, welche Verknüpfungen fachlich benötigt werden und welche die gewählte Konfiguration tatsächlich verhindert.
4. Ausgefüllte Freigabematrix für einen Beispielbetrieb
Das fiktive Unternehmen Elbwerk verbindet ein Projektportal und ein Schulungsportal mit einem zentralen Identitätsdienst. Die folgende Matrix beschreibt eine interne Entscheidung dieses Beispiels, keine allgemeine Mindestkonfiguration und keine Aussage über einen bestimmten Anbieter.
| Gegenstand | Entscheidung bei Elbwerk | Nachweis vor Freigabe |
|---|---|---|
| Projektportal | Stabile anwendungsspezifische Kennung, Anzeigename und freigegebene Projektrolle | Beispielantwort enthält keine übrigen Gruppen |
| Schulungsportal | Kennung und Kurszuordnung; E-Mail nur für ausdrücklich aktivierte Benachrichtigungen | Attributliste stimmt mit Portalzwecken überein |
| Administration | Eigenes Administrationskonto mit stärker geschützter Authentisierung | Alltagskonto kann keine Vertrauensbeziehung ändern |
| Ausscheiden | Zentrales Konto sperren, Rollen entfernen, Anwendungssitzungen beenden und technische Zugänge gesondert prüfen | Protokoll eines durchgespielten Austritts |
| Ausfall | Fachverantwortliche priorisieren dringende Vorgänge; dokumentierter Notzugang nur für notwendige Administration | Wiederherstellung mit benannten Verantwortlichen erprobt |
| Protokolle | Sicherheitsereignisse getrennt vom fachlichen Bearbeitungsverlauf auswerten | Zweck, Zugriff und Löschung je Protokollquelle festgelegt |
Für ein Postfach nach dem Ausscheiden eines Mitarbeiters reicht die zentrale Kontosperre als Entscheidung nicht aus. Ob andere Beschäftigte geschäftliche Nachrichten benötigen und wie private Kommunikation geschützt wird, ist vor einer Freigabe getrennt vom technischen Entzug der Anmeldung festzuhalten.
Die Freigabe lautet beispielsweise: „Projektportal freigegeben, nachdem der vollständige Gruppenexport durch die Projektrolle ersetzt wurde. Schulungsportal zunächst nur für den Pilotbereich. Offener Befund: Die lokale Sitzung bleibt nach zentraler Sperre aktiv; vor dem allgemeinen Einsatz muss die Anwendung den vereinbarten Sperrablauf umsetzen.“
Dieser Vermerk macht den offenen Punkt sichtbar. Eine allgemeine Zusicherung, dass der Dienst SSO unterstützt, würde die konkrete Schwachstelle nicht beschreiben. Die fachliche Freigabe sollte außerdem benennen, wer das verbleibende Risiko bis zur Behebung verantwortet und welche Nutzung währenddessen ausgeschlossen ist.
5. Authentisierung und Berechtigungen getrennt gestalten
Eine erfolgreiche Anmeldung beantwortet zunächst, welcher Identität die Anwendung vertrauen kann. Sie beantwortet nicht abschließend, welche Kundendaten diese Person sehen darf. Eine Projektrolle muss innerhalb der Anwendung auf die zulässigen Projekte und Handlungen begrenzt werden. Der bloße Besitz eines gültigen Tokens darf nicht sämtliche Datensätze zugänglich machen.
Für die zentrale Anmeldung gehören Mehrfaktorauthentisierung, sichere Wiederherstellung und besonders geschützte Administrationskonten in die Risikobewertung. Die Passwort- und Authentisierungsrichtlinie sollte auch festlegen, wer einen verlorenen Faktor ersetzen darf und welche Nachweise dafür ausreichen. Eine starke Anmeldung verliert ihren Nutzen, wenn der Helpdesk sie über eine ungeprüfte Nachricht zurücksetzen kann.
Bei OAuth-basierten Integrationen liefert RFC 9700 die aktuelle Sicherheitsgrundlage: unter anderem präzise registrierte Rücksprungadressen, Schutz gegen eingeschleuste Autorisierungscodes und angemessene Tokenbegrenzung. Öffentliche Clients müssen PKCE verwenden; für vertrauliche Clients wird es empfohlen. Das Integrationsteam sollte den eingesetzten Ablauf und seine Schutzmaßnahmen nachweisen können. Ein selbst gebautes Verfahren allein aufgrund eines kurzen Codebeispiels ist keine belastbare Betriebsentscheidung.
6. Abmeldung, Kontosperre und Sitzungsende nachweisen
Eine Abmeldung im Projektportal kann lediglich dessen eigene Sitzung beenden. Umgekehrt muss eine zentrale Abmeldung den angebundenen Anwendungen zuverlässig mitgeteilt und von ihnen verarbeitet werden. Die Spezifikation für RP-initiierte Abmeldung beschreibt dafür den Aufruf des zentralen Abmeldeendpunkts und das Zusammenspiel mit unterstützten Benachrichtigungsverfahren. Sie weist auch darauf hin, dass Benachrichtigungen je nach Verfahren unzuverlässig sein können.
Lassen Sie deshalb drei unterschiedliche Abläufe demonstrieren: freiwillige Abmeldung, administrative Kontosperre und Entzug einer einzelnen Rolle. Prüfen Sie jeweils ein bereits geöffnetes Browserfenster, eine laufende mobile Sitzung und gegebenenfalls einen API-Zugriff. Dokumentieren Sie, ab wann weitere Aktionen tatsächlich zurückgewiesen werden. Ein ausgeblendeter Menüpunkt allein belegt keinen serverseitigen Rechteentzug.
Die zulässige Verzögerung richtet sich nach dem Risiko. Ein internes Kursportal kann anders bewertet werden als der Zugriff auf sensible Personalakten. Notieren Sie die konkrete Frist als interne Entscheidung samt Begründung; stellen Sie sie nicht als pauschale DSGVO-Vorgabe dar.
7. Datenschutzrollen, Protokolle und Dienstleister prüfen
Bei einem externen Identitätsdienst ist zu klären, welche Verarbeitung im Auftrag erfolgt und ob zusätzliche eigene Zwecke bestehen. Werbung, eigenständige Produktanalysen oder anwendungsübergreifende Profile dürfen nicht hinter dem Begriff „Anmeldung“ verschwinden. Für die Vertragswahl hilft die Abgrenzung zwischen Verantwortlichem und Auftragsverarbeiter.
Anmeldeprotokolle können Kontokennungen, Zeitpunkte, IP-Adressen und Informationen über verwendete Anwendungen enthalten. Bestimmen Sie, welche Ereignisse der Angriffserkennung dienen, wer sie einsehen darf und wann sie gelöscht werden. Eine spätere Leistungsbewertung von Beschäftigten ist kein selbstverständlicher Bestandteil des Sicherheitszwecks. Das Protokollierungskonzept verbindet Ereigniskatalog, Zugriff und Aufbewahrung mit nachvollziehbaren Entscheidungen.
Erfassen Sie auch Standorte und Fernzugriffe des Dienstleisters. Ein europäischer Mandant schließt einen Drittlandzugriff durch Support nicht automatisch aus. Der Datenfluss muss dieselben Identitätsattribute, Protokolle und Wiederherstellungsinformationen abdecken, die tatsächlich verfügbar werden. Änderungen an Unterauftragnehmern oder Supportregionen gehören deshalb in die laufende Bewertung.
8. Auswahl und Betrieb mit konkreten Nachweisen steuern
Vergleichen Sie Anbieter anhand der benötigten Integrationen, der Attributsteuerung, des Entzugs bestehender Zugriffe und des Wiederanlaufs. Verlangen Sie für jede kritische Anwendung einen beobachtbaren Ablauf. Ein gutes Angebot nennt außerdem Grenzen: etwa welche Altanwendung keinen zentralen Sitzungsentzug unterstützt oder welche Funktion eine zusätzliche Lizenz voraussetzt.
Im Betrieb braucht jede Vertrauensbeziehung einen Eigentümer. Dieser prüft Änderungen an Attributen, Zertifikaten, Rücksprungadressen und Rollen. Unbenutzte Anbindungen werden entfernt. Notzugänge werden geschützt aufbewahrt, nach Nutzung überprüft und regelmäßig auf ihre Funktionsfähigkeit kontrolliert. Die Informationssicherheitsrichtlinie kann diese Zuständigkeiten verbindlich zuweisen.
Für die nächste Überprüfung genügen wenige aussagekräftige Fragen: Funktioniert der Austrittsablauf noch? Werden inzwischen zusätzliche Attribute übertragen? Ist der Wiederherstellungsweg weiterhin abgesichert? Kann eine ausgefallene Abhängigkeit innerhalb des fachlich vertretbaren Zeitraums ersetzt werden? Die Antworten müssen sich an der laufenden Konfiguration belegen lassen.
Häufige Fragen
Macht SSO eine Anwendung automatisch DSGVO-konform?
Nein. SSO kann Sicherheitsmaßnahmen unterstützen. Rechtsgrundlage, Datenumfang, Transparenz, Dienstleisterrolle und die Rechte innerhalb der Anwendung müssen weiterhin passen. Auch eine technisch einwandfreie Anmeldung legitimiert keinen unnötigen Datenexport.
Ist eine zentrale Anmeldung immer besser als lokale Konten?
Sie kann Administration und Schutz verbessern, schafft aber eine gemeinsame Abhängigkeit. Entscheidend ist, ob der konkrete Betrieb starke Authentisierung, begrenzte Berechtigungen, wirksame Sperren und Wiederherstellung tatsächlich umsetzt. Eine unvollständige Migration kann zusätzliche Umgehungswege offenlassen.
Welcher Nachweis ist für den Projektabschluss besonders nützlich?
Eine ausgefüllte Attribut- und Berechtigungsmatrix zusammen mit einem nachvollziehbaren Austritts- und Ausfallszenario. Damit wird sichtbar, welche Daten fließen, wer Zugriff erhält und wie dieser Zugriff wieder endet.