SSO löst den Login. Aber nicht automatisch den Benutzer-Lifecycle

Ein neuer Mitarbeiter startet. Sein Konto im zentralen Identity Provider ist angelegt, er klickt auf das LMS und landet ohne zusätzliches Passwort direkt im System. Perfekt. Single Sign-On funktioniert.

Drei Monate später wechselt er die Rolle. Ein Jahr später verlässt er das Unternehmen.

Und genau dann zeigt sich, ob wirklich die Benutzerverwaltung integriert wurde oder nur der Login.

Diese beiden Dinge werden in Softwareprojekten erstaunlich oft zusammengeworfen. In Anforderungslisten steht dann „SSO vorhanden“, als wäre damit geklärt, wie Nutzer angelegt, Rollen geändert und Konten beim Offboarding deaktiviert werden. Technisch beantwortet SSO zunächst eine viel engere Frage: Wie weist ein Nutzer seine Identität gegenüber einer Anwendung nach?

Provisioning beantwortet eine andere: Wie kommt die Identität überhaupt in die Anwendung, wie bleibt sie aktuell und was passiert, wenn sie dort nicht mehr gebraucht wird?

SSO beantwortet die Login-Frage

Bei SAML-basiertem Web Single Sign-On gibt es vereinfacht zwei Rollen: einen Identity Provider und einen Service Provider. Der Identity Provider kennt und authentifiziert den Nutzer. Die Zielanwendung vertraut dieser Identität und kann daraus eine lokale Sitzung erzeugen.

Der OASIS-Überblick zu SAML beschreibt genau diesen Ablauf. Der Nutzer authentifiziert sich beim Identity Provider. Dieser stellt eine Assertion aus, die der Service Provider verarbeitet. Der Nutzer muss sich dadurch nicht für jede angebundene Anwendung erneut mit einem separaten Passwort anmelden.

Das ist ein großer operativer Gewinn. Passwörter müssen nicht in jeder Anwendung separat verwaltet werden. Login-Regeln können zentralisiert werden. Ein Unternehmen kann seine bestehende Identitätsinfrastruktur für viele Dienste nutzen.

Aber damit ist noch nicht entschieden, wie der Datensatz des Nutzers in der Zielanwendung verwaltet wird.

SAML kann zwar Attribute wie Name, E-Mail-Adresse oder Gruppeninformationen übertragen. Das ändert aber nichts an der Grundfrage: Was geschieht mit dem lokalen Nutzerobjekt, wenn sich außerhalb des Login-Moments etwas ändert?

Ein Login ist noch kein Benutzer-Lifecycle

Ein Unternehmensnutzer durchläuft normalerweise mehr als einen Zustand.

Er kommt ins Unternehmen. Er wird einer Organisationseinheit zugeordnet. Seine Rolle ändert sich. Er wechselt vielleicht von einer Tochtergesellschaft in eine andere. Er bekommt zusätzliche Verantwortlichkeiten. Später verliert er bestimmte Berechtigungen oder verlässt das Unternehmen vollständig.

Das BSI beschreibt Identitäts- und Berechtigungsmanagement deshalb ausdrücklich als Prozess für die Zuweisung, den Entzug und die Kontrolle von Rechten. Authentifizierung ist ein Teil davon, aber nicht das ganze Modell.

Für eine angebundene SaaS-Anwendung entstehen daraus mindestens drei zusätzliche Fragen:

1. Wer erzeugt den Nutzer in der Anwendung?
2. Wer hält Attribute, Gruppen oder Rollen aktuell?
3. Wer deaktiviert oder entfernt den Nutzer wieder?

Wenn die Antwort auf alle drei Fragen „ein Administrator macht das manuell“ lautet, kann SSO trotzdem technisch einwandfrei funktionieren.

JIT liegt genau zwischen beiden Welten

Ganz so sauber lässt sich die Welt allerdings nicht in „SSO macht Login“ und „SCIM macht Benutzerverwaltung“ aufteilen.

Viele Anwendungen unterstützen Just-in-Time-Provisioning, kurz JIT. Dabei existiert ein Nutzer vor seinem ersten Login noch gar nicht lokal. Erst wenn er sich erfolgreich per SSO anmeldet, legt die Anwendung anhand der übermittelten Attribute ein lokales Konto an.

Das ist praktisch. Gerade beim Onboarding spart es separate Import- oder Anlageprozesse.

Microsoft beschreibt für SAML JIT außerdem, dass vorhandene Nutzerinformationen beim Login aktualisiert werden können. Damit übernimmt der SSO-Prozess tatsächlich einen Teil des Provisionings.

Die Grenze zeigt sich beim Offboarding. In der Microsoft-Dokumentation steht ebenso klar: SAML JIT kann Nutzer in der Zielanwendung nicht löschen oder deaktivieren.

Das bedeutet nicht automatisch, dass ein ausgeschiedener Mitarbeiter weiterhin Zugriff hat. Wenn SSO verpflichtend ist und sein Konto beim Identity Provider deaktiviert wurde, kann die nächste Authentifizierung scheitern. Abhängig von der konkreten Anwendung kann der Zugriff damit bereits wirksam unterbunden sein.

Trotzdem können in der Zielanwendung weiterhin ein lokales Konto, Rollenzuordnungen, Lizenzen, Gruppenmitgliedschaften oder fachliche Zuweisungen bestehen. Auch Rollenwechsel werden nicht zuverlässig dadurch verarbeitet, dass jemand irgendwann wieder einen Login ausführt.

Deshalb ist JIT eine sinnvolle Zwischenlösung, aber keine automatische Antwort auf den vollständigen Lifecycle.

Was SCIM tatsächlich standardisiert

Hier setzt SCIM an: System for Cross-domain Identity Management.

Die IETF-Spezifikationen RFC 7643 und RFC 7644 definieren ein gemeinsames Schema und ein HTTP-basiertes Protokoll für Identitätsressourcen wie Nutzer und Gruppen. Ein Identity- oder Provisioning-System kann damit gegenüber einer Zielanwendung typische Verwaltungsoperationen ausführen, etwa Nutzer erzeugen, lesen, ändern oder entfernen.

Der wesentliche Unterschied zu SSO liegt nicht darin, dass SCIM „moderner“ wäre. Es löst schlicht ein anderes Problem.

SSO arbeitet vor allem in dem Moment, in dem jemand Zugang zu einer Anwendung benötigt. Provisioning arbeitet am Zustand der Identität in der Anwendung.

Dadurch kann eine Änderung im führenden System auch dann verarbeitet werden, wenn der betroffene Nutzer sich gerade nicht anmeldet.

Das ist für drei typische Situationen relevant:

• Joiner: Ein neuer Mitarbeiter kann bereits vor seinem ersten Login in den benötigten Anwendungen angelegt und den richtigen Gruppen zugeordnet werden.
• Mover: Ändert sich Abteilung, Rolle oder Gruppenzugehörigkeit, kann diese Änderung in die Zielsysteme übertragen werden.
• Leaver: Wird eine Identität aus dem vorgesehenen Scope entfernt oder deaktiviert, kann auch die Zielanwendung entsprechend reagieren.

Damit wird aus einer Login-Integration ein Lifecycle-Prozess.

SCIM ist trotzdem nicht automatisch „fertige Benutzerverwaltung“

Auch ein SCIM-Logo auf einer Featureliste sollte man nicht mit einer vollständigen Lösung verwechseln.

Microsoft beschreibt in seiner Implementierungsdokumentation mehrere Schritte, die trotz standardisiertem Protokoll konfiguriert werden müssen: Attribut-Mappings, Scoping-Regeln, die Auswahl der zu synchronisierenden Nutzer und Gruppen, Tests sowie die Überwachung der Provisioning-Logs.

Das ist logisch. Ein Standard kann festlegen, wie Systeme Informationen austauschen. Er kann nicht für jedes Unternehmen entscheiden, welche Information führend ist und welche fachliche Bedeutung sie in einer konkreten Anwendung hat.

Ein Beispiel: Der Identity Provider kennt vielleicht die Abteilung „Vertrieb Deutschland“. Das LMS arbeitet aber mit Mandanten, Organisationseinheiten und Lernrollen. Dann muss geklärt sein, ob und wie diese Strukturen aufeinander abgebildet werden.

Dasselbe gilt für Gruppen. „SCIM unterstützt Gruppen“ beantwortet noch nicht, ob eine Gruppenmitgliedschaft im Zielsystem automatisch eine bestimmte Administratorrolle, Kurszuweisung oder organisatorische Struktur auslösen soll.

Die richtige Frage lautet deshalb nicht nur: Unterstützt das System SCIM?

Sondern: Welche Objekte und Attribute werden tatsächlich synchronisiert und was bewirkt eine Änderung im Zielsystem?

SCIM ist nicht die einzige Lösung

Aus der bisherigen Abgrenzung könnte man jetzt die nächste zu einfache Einkaufsregel bauen: Enterprise-Software ohne SCIM ist grundsätzlich ungeeignet.

Auch das wäre falsch.

Microsoft selbst nennt neben SCIM weitere Wege für automatisiertes Provisioning, darunter APIs und eigene Connectoren. Eine Anwendung kann ihren Lifecycle genauso über eine saubere REST-Schnittstelle, Middleware oder einen spezialisierten Connector abbilden.

SCIM hat einen wichtigen Vorteil: Es standardisiert einen häufig wiederkehrenden Teil der Identitätsverwaltung. Dadurch müssen Identity Provider und Anwendungen nicht für jede Integration ein komplett eigenes Benutzerprotokoll erfinden.

Aber der eigentliche Unternehmensbedarf lautet nicht „Wir brauchen SCIM“.

Er lautet: Wir brauchen einen verlässlichen Prozess, durch den die richtigen Identitäten mit den richtigen Eigenschaften zur richtigen Zeit in der Anwendung vorhanden sind und wieder entzogen werden.

Wenn eine andere Integration diesen Prozess belastbar erfüllt, ist das zunächst genauso legitim.

Fünf Fragen statt „Habt ihr SSO?“

Für eine LMS-, HR-, Wissens- oder andere SaaS-Auswahl lässt sich die technische Prüfung deshalb deutlich besser strukturieren.

Die Kontoanlage ist besonders wichtig, wenn bereits vor dem ersten Zugriff Zuweisungen, Schulungen oder Berechtigungen vorhanden sein sollen. Bei Rollenwechseln reicht ein reiner JIT-Prozess häufig nicht aus, weil Änderungen sonst womöglich erst beim nächsten Login sichtbar werden.

Beim Offboarding ist „löschen“ ebenfalls nicht automatisch das richtige Ziel. Für Nachweise oder Historien kann es notwendig sein, Datensätze kontrolliert zu erhalten. Entscheidend ist ein definierter Zielzustand.

Und Automatisierung ohne Kontrolle verschiebt manuelle Pflege sonst nur in eine schwer sichtbare Fehlerklasse.

Der wichtigste Test kommt nicht beim ersten Login

SSO lässt sich hervorragend demonstrieren. Nutzer klickt, wird weitergeleitet, ist eingeloggt. Fertig.

Der schwierigere Teil einer Identity-Integration zeigt sich später.

Was passiert, wenn der Nutzer die Abteilung wechselt? Wenn eine Gruppe entzogen wird? Wenn ein Mitarbeiter heute ausscheidet, aber seine Schulungshistorie für einen späteren Nachweis erhalten bleiben muss? Wenn ein Provisioning-Lauf fehlschlägt?

Genau deshalb sollte „SSO vorhanden“ nie das Ende einer Integrationsprüfung sein.

Es ist die Antwort auf die erste Frage.

Eine belastbare Unternehmensintegration beantwortet auch die nächsten vier.