Wenn wir die Anwendungen eines Kunden an einen einzigen Identity Provider anbinden, steht früh im Plan dieselbe Zeile: „Und SCIM 2.0 brauchen wir auch.“ Das klingt nach einem Teil von Single Sign-on. Ist es nicht, und in vielen Integrationen können Sie es weglassen. In einem unserer Projekte haben wir auf SCIM verzichtet und stattdessen einen Joiner-Mover-Leaver-Mechanismus (JML) gebaut; mehr dazu unten.
Zwei verschiedene Aufgaben
SSO beantwortet eine Frage: Wer ist dieser Benutzer, jetzt gerade? Die Anwendung schickt den Benutzer zum Identity Provider (IdP), der IdP authentifiziert ihn und liefert eine signierte Antwort zurück, ein OpenID-Connect-ID-Token oder eine SAML-Assertion, und die Anwendung prüft sie und meldet den Benutzer an.
SCIM 2.0 (RFC 7643 und RFC 7644) beantwortet eine andere: Welche Konten sollen in dieser Anwendung existieren, mit welchen Attributen und Gruppen? Der IdP ruft eine API der Anwendung auf, um Benutzer anzulegen, zu ändern und zu deaktivieren, ob sie sich je anmelden oder nicht.
| Aspekt | SSO (OIDC oder SAML) | SCIM 2.0 |
|---|---|---|
| Frage | Wer meldet sich an? | Welche Konten existieren? |
| Wann es läuft | Bei jeder Anmeldung | Wenn sich ein Benutzer im IdP ändert |
| Wer ruft wen | Browser-Weiterleitungen, dazu der Aufruf der Anwendung am Token-Endpunkt des IdP (OIDC) | Der IdP ruft die API der Anwendung auf |
| Was Sie bauen | Einen Anmeldeablauf und die Token-Prüfung | Einen /scim/v2-Endpunkt, der jahrelang betrieben wird |
Was SSO allein abdeckt
Auch ohne SCIM kann eine Anwendung ihre Konten nah am IdP halten:
- Anlegen bei der ersten Anmeldung. Just-in-time-Provisionierung legt das Konto aus den Claims im Token an, wenn sich die Person zum ersten Mal anmeldet.
- Aktualisieren bei jeder Anmeldung. Name, E-Mail und Gruppen-Claims werden jedes Mal neu gelesen, sodass die Rollen dem IdP von Anmeldung zu Anmeldung folgen. Prüfen Sie, ob der IdP Gruppen überhaupt sendet: Manche lassen sie standardmäßig weg oder listen sie ab einer Größengrenze nicht mehr auf.
- Über eine stabile Kennung verknüpfen. Speichern Sie Aussteller und Subject (
issundsuboder eine persistente SAML-NameID), nie die E-Mail-Adresse, die sich ändern oder nach einem Austritt wiederverwendet werden kann. - Ausgeschiedene bleiben draußen. Sobald das IdP-Konto deaktiviert ist, gelingt keine neue Anmeldung mehr.
Für eine Gruppe von Systemen, in die sich die Leute täglich anmelden, reicht das meist, und es erspart den Bau und Betrieb eines SCIM-Endpunkts in jeder Anwendung.
Was es nicht abdeckt
SSO sieht einen Benutzer nur, wenn er sich anmeldet. Planen Sie die Lücken ein, statt sie bei einem Audit zu entdecken:
- Offene Sitzungen und Refresh-Tokens einer ausgeschiedenen Person bleiben gültig, bis sie ablaufen. Halten Sie sie kurz oder nutzen Sie Back-Channel-Logout, wo der IdP es unterstützt.
- API-Schlüssel und persönliche Zugriffstokens laufen nie über den IdP. Binden Sie sie an das Konto und prüfen Sie, ob es noch aktiv ist; das funktioniert nur zusammen mit dem nächsten Punkt.
- Ein Konto existiert erst nach der ersten Anmeldung, also kann niemand einer neuen Kollegin oder einem neuen Kollegen vorab Aufgaben oder Rechte zuweisen.
- Niemand teilt der Anwendung mit, dass eine Person gegangen ist, also bleibt das Konto in ihrer Datenbank. Ein regelmäßiger Abgleich mit dem Verzeichnis, etwa Microsoft Graph oder LDAP, kann es deaktivieren.
Wann sich SCIM lohnt
Setzen Sie SCIM ein, wenn eine dieser Anforderungen verbindlich ist: Konten müssen vor der ersten Anmeldung existieren, der Zugriff muss kurz nach einem Austritt in allen Anwendungen entzogen werden, ohne auf eine Anmeldung der Person zu warten, oder ein Prüfer erwartet, dass die Benutzerliste jeder Anwendung mit dem IdP synchron gehalten wird. Dann ist SCIM der Standardweg, und die großen Identity Provider unterstützen ihn. Es ist nicht der einzige: Ein eigener Joiner-Mover-Leaver-Prozess kann dieselben Anforderungen abdecken. Keiner von beiden beendet offene Sitzungen von selbst, also widerrufen Sie sie, sobald ein Konto deaktiviert wird.
Was wir stattdessen gemacht haben: einen JML-Mechanismus
In einem unserer Projekte haben wir auf SCIM verzichtet und einen JML-Mechanismus gebaut. SCIM hätte einen standardisierten Provisioning-Endpunkt in jeder Anwendung bedeutet, und das Widerrufen von Sitzungen und Tokens wäre trotzdem unsere Aufgabe geblieben. Ein JML-Mechanismus steuert den Lebenszyklus des Zugriffs einer Person direkt:
- Joiner. Konten und Startrollen werden bei der Einstellung angelegt, typischerweise aus dem HR-System, noch vor der ersten Anmeldung.
- Mover. Ein Team- oder Rollenwechsel fügt den neuen Zugriff hinzu und entzieht den alten, damit sich Rechte nicht ansammeln.
- Leaver. Konten werden deaktiviert und Sitzungen und Tokens widerrufen, statt nur die nächste Anmeldung zu blockieren.
Wie SCIM braucht er einen Integrationspunkt in jeder Anwendung; der Unterschied ist, dass Sie den Lebenszyklus an Ihren eigenen Systemen ausrichten statt an einem Standardprotokoll. SSO bleibt für die Anmeldung zuständig; JML entscheidet, worauf Personen Zugriff haben und wann dieser endet.
Tipp
Trifft keine dieser Anforderungen zu, beginnen Sie nur mit SSO: Konten über das Subject verknüpfen, Sitzungen kurz halten und SCIM oder einen JML-Prozess später ergänzen, falls die Anforderung entsteht. Speichern Sie von Anfang an zusätzlich eine Kennung, die der IdP per SCIM als externalId senden kann (in Microsoft Entra ID die Objekt-ID), damit provisionierte und bestehende Konten zusammenpassen. So oder so erweitert die Provisionierung dieselben Konten; sie ersetzt die Anmeldung nicht.