SCIM-Provisionierung: Warum die Deprovisionierung von allen falsch verstanden wird

Was SCIM eigentlich ist

SCIM steht für System for Cross-domain Identity Management. Es ist ein offener Standard – das Schema ist in RFC 7643, das Protokoll in RFC 7644 definiert –, der eine REST-API für den Austausch von Identitätsdaten zwischen Systemen festlegt. Version 2.0 ist der Standard, den alle großen IdPs implementieren.

Das zugrunde liegende Konzept ist einfacher als das Akronym. Ihr IdP fungiert als Client, die nachgelagerte Anwendung als Server. Der IdP verwaltet eine Liste von Personen und Gruppen; sobald sich diese Liste ändert, sendet er einen entsprechenden HTTP-Aufruf.

SCIM definiert zwei Ressourcen-Sammlungen, auf denen das gesamte Protokoll basiert:

Die vorletzte Zeile ist entscheidend. SCIM bietet eine erstklassige, standardisierte Methode, um zu sagen: diese Person sollte keinen Zugriff mehr haben – und dieses Signal stammt von dort, wo das Ausscheiden einer Person bereits erfasst ist: bei der HR-gestützten Identitätsverwaltung, nicht in einer von der IT verwalteten Tabelle.

SCIM ist nicht SSO, und dieser Unterschied ist wichtig

SSO beantwortet zum Zeitpunkt der Anmeldung eine Frage: Ist diese Person die, die sie vorgibt zu sein? Eine SAML-Assertion oder ein OIDC-Token trifft ein, die Anwendung validiert es, und die Sitzung beginnt.

SCIM beantwortet kontinuierlich eine Frage: Sollte diese Person hier überhaupt existieren? Dies geschieht nach einem eigenen Zeitplan, unabhängig davon, ob sich gerade jemand anmeldet.

Die Lücke zwischen diesen beiden Ansätzen ist das eigentliche Problem. Wenn Sie SSO nur mit Just-in-Time-Kontoerstellung betreiben, bewacht Ihr IdP zwar den Haupteingang, aber die Konten im Hintergrund sammeln sich unbegrenzt an. Die Deaktivierung einer Person im IdP blockiert zwar neue Anmeldungen, aber das Kontoobjekt bleibt bestehen – weiterhin verknüpft mit allen Rollen, Mitgliedschaften und – was bei einer KI-Plattform besonders kritisch ist – allen API-Schlüsseln und Service-Tokens, die es angesammelt hat.

Warum die Deprovisionierung von allen falsch angegangen wird

Onboarding ist ein lautes Versagen. Offboarding ist ein stilles. Diese Asymmetrie erklärt fast jeden Befund bei Zugriffsüberprüfungen, den wir je gesehen haben.

Niemand beschwert sich über Zugriffsrechte, die er eigentlich nicht haben sollte. Wenn die Provisionierung fehlschlägt, meldet sich ein neuer Ingenieur innerhalb von zwanzig Minuten in einem Kanal. Wenn die Deprovisionierung fehlschlägt, hat der Begünstigte das Unternehmen bereits verlassen. Es gibt keinen Feedback-Mechanismus, daher bleibt der Fehler bestehen, bis ein Prüfer ihn entdeckt.

Manuelle Offboarding-Checklisten veralten mit der Zeit. Die Checkliste wird erstellt, wenn das Unternehmen acht SaaS-Tools nutzt. Zwei Jahre später sind es sechzig, aber die Checkliste enthält immer noch acht.

Die Verweildauer ist lang. Da das Problem meist unbemerkt bleibt, werden verwaiste Konten oft über Monate hinweg nicht erkannt und erst bei einem Audit oder einem Sicherheitsvorfall entdeckt – den zwei ungünstigsten Zeitpunkten für eine solche Entdeckung.

Auf KI-Plattformen ist ein verwaistes Konto mehr als nur ein Login. Ein veralteter Benutzerdatensatz kann mit Anmeldedaten für Modellanbieter, MCP-Serverzugriffen, bereitgestellten Workloads und langlebigen API-Schlüsseln verknüpft sein. Browsersitzungen laufen von selbst ab. Programmatische Anmeldedaten hingegen nicht. Deshalb muss API-Authentifizierung und RBAC in einem KI-Gateway identitätsbasiert statt schlüsselbasiert sein – ein Schlüssel ohne Besitzer ist ein Schlüssel, den niemand jemals widerrufen wird.

SCIM eliminiert den manuellen Schritt. Der Austritt wird einmalig im IdP erfasst und von dort aus weitergegeben.

SCIM vs. JIT vs. Nur-auf-Einladung: Welcher Bereitstellungsmodus ist der richtige?

TrueFoundry unterstützt drei Bereitstellungsmodi, wobei ein Mandant jeweils nur einen davon nutzt. Dies ist die Entscheidung, die die meisten Teams eigentlich treffen wollen, wenn sie nach SCIM suchen.

Aus dieser Tabelle lassen sich drei Erkenntnisse ableiten.

JIT ist kein leichtgewichtiges SCIM. Es ist nur die Hälfte von SCIM – die sichtbare Hälfte. Es sorgt dafür, dass eine neue Person problemlos und ohne Konfigurationsaufwand ein Konto erhält. Es unternimmt jedoch nichts, wenn eine Person das Unternehmen verlässt. Wenn Sie sich für JIT entscheiden, weil Sie „das Offboarding manuell erledigen wollen“, sollten Sie ehrlich hinterfragen, wer für diesen Schritt verantwortlich ist und wie er auditiert wird.

„Nur auf Einladung“ ist keine schlechtere Option, sondern eine andere. Für einen Auftragnehmer bei einer Partnerfirma, der nicht in Ihrem IdP geführt wird, ist eine Einladung der richtige Mechanismus. Das Problem entsteht, wenn man dies für Mitarbeiter nutzt, die bereits in Ihrem IdP vorhanden sind, da Ihre Administratoren dann zu einer manuellen Kopie eines Systems werden, für das Sie bereits bezahlen.

Die Gruppensynchronisierung ist der Punkt, den die meisten unterschätzen. Das automatische Anlegen von Benutzern spart pro Einstellung ein paar Minuten. Die Synchronisierung von Gruppen sorgt jedoch dafür, dass die Autorisierung dauerhaft korrekt bleibt – ein fortlaufender Nutzen statt einer einmaligen Erleichterung.

Wo Teams Fehler machen

SSO mit Deprovisionierung gleichsetzen. Der häufigste Fehler, der durchaus nachvollziehbar ist, da die Deaktivierung eines Benutzers im IdP neue Anmeldungen blockiert. Was dabei jedoch nicht passiert, ist das Löschen des Kontos, der Gruppenzugehörigkeiten oder der hinterlegten Anmeldedaten. Die Vordertür zu blockieren ist nicht dasselbe, wie das Konto zu schließen.

Gruppennamen, die bei der Synchronisierung lautlos scheitern. Jedes Provisionierungssystem hat Namenskonventionen, und IdP-Gruppen werden meist von Leuten benannt, die diese nie gelesen haben. Eine Gruppe namens ML Platform — Prod (EMEA) enthält ein Leerzeichen, einen Gedankenstrich und Klammern und wird daher downstream nicht als gültiges Team erkannt. Das Scheitern bleibt unbemerkt: Benutzer werden synchronisiert, die Gruppe jedoch nicht, und niemand merkt etwas, bis jemand fragt, warum das Team leer ist.

Annahme, dass SCIM alle Berechtigungen einer Person erfasst. SCIM synchronisiert Benutzer und Gruppenzugehörigkeiten. Es weiß nichts von Berechtigungen, die direkt und außerhalb einer Gruppe für eine bestimmte Ressource vergeben wurden. Entfernt man jemanden aus einem Team, bleiben die direkten Berechtigungen bestehen. Dies ist die häufigste Antwort auf die Frage: „Warum kann diese Person das immer noch sehen?“

Unsachgemäße oder fehlende Speicherung des SCIM-Tokens. Das Bearer-Token wird nur einmal angezeigt. Teams fügen es in den IdP ein, schließen den Tab und speichern keine Kopie. Das ist zwar kein Weltuntergang – man kann ein neues generieren –, aber dadurch wird das alte ungültig, sodass die Provisionierung stoppt, bis auch der IdP aktualisiert wurde. Speichern Sie es in Ihrem Secret-Manager, bevor Sie den Tab schließen.

Want to see the lifecycle end to end?

Spin up a TrueFoundry tenant, wire up your IdP, and watch a group become a team.

Get started free

So funktioniert die SCIM-Provisionierung in TrueFoundry

TrueFoundry unterstützt SCIM sowohl für OIDC- als auch für SAML v2-SSO-Konfigurationen. Bevor Sie die Provisionierung konfigurieren, muss SSO funktionieren – die SCIM-URL und das Token befinden sich direkt bei der SSO-Konfiguration und nicht in einer separaten Integration.

Schritt 1 – SSO konfigurieren

Gehen Sie zu Platform → Settings → SSO, aktivieren Sie Enabled, wählen Sie Ihren Anbieter aus und entscheiden Sie sich für OIDC oder SAML v2.

TrueFoundry-Bildschirm für SSO-Einstellungen mit dem Aktivierungsschalter, der Auswahl des SSO-Anbieters und dem Bereich für die Authentifizierungskonfiguration

Für OIDC geben Sie eine Client-ID, ein Client-Secret und eine Issuer-URL an; die Callback-URL auf der Seite des IdP lautet immer https://login.truefoundry.com/oauth2/callback. Für SAML geben Sie die IdP-SSO-URL sowie ein X.509-Signaturzertifikat an und kehren nach dem Speichern zurück, um die Callback-URL und Issuer-URL von TrueFoundry zu generieren und in Ihren IdP einzufügen.

SAML-Metadaten-Panel in TrueFoundry mit den generierten Werten für Callback-URL und Issuer, die in den Identitätsanbieter kopiert werden müssen

Ein Detail, das später Zeit spart: Konfigurieren Sie Ihren IdP so, dass er Claims mit den Namen email, sub und groups ausgibt. Dies sind die Standardwerte von TrueFoundry. Wenn Sie die Attribute auf der IdP-Seite entsprechend zuordnen, müssen Sie die erweiterten Felder nicht bearbeiten.

Okta-Bildschirm zur Zuordnung von SAML-Attributen mit den Attributanweisungen für email, sub und groups

Schritt 2 — SCIM aktivieren

Gehen Sie zu Einstellungen → Sicherheit & Zugriff → Bereitstellung und wählen Sie SCIMaus. Hier befinden sich alle drei Bereitstellungsmodi; durch die Auswahl eines Modus legen Sie das Lebenszyklusmodell des Mandanten fest.

Seite für Bereitstellungseinstellungen mit den Optionen für SCIM, Just-in-Time- und Nur-auf-Einladung-Bereitstellungsmodi

Schritt 3 — SCIM-Basis-URL kopieren

Erweitern Sie Ihre gespeicherte SSO-Konfiguration, um die SCIM-URL zusammen mit den restlichen Metadaten anzuzeigen. Dies ist der Wert, den Ihr IdP aufruft.

Erweiterte SSO-Konfigurationszeile, die die SCIM-URL zusammen mit anderen Verbindungsmetadaten anzeigt

Schritt 4 – SCIM-Token generieren

Klicken Sie auf das Schlüsselsymbol neben der SSO-Konfiguration, um das SCIM-Authentifizierungs-Token zu generieren.

Schlüsselsymbol neben einer SSO-Konfigurationszeile mit der Option, ein SCIM-Token zu generieren und zu kopieren

Behandeln Sie es wie ein Passwort. Es wird nur bei der Erstellung angezeigt; wenn Sie es verlieren, generieren Sie ein neues, wodurch das vorherige Token ungültig wird.

Schritt 5 – IdP darauf verweisen

Legen Sie in den Bereitstellungseinstellungen Ihres IdP die Basis-URL (manche IdPs nennen sie Tenant-URL) auf die SCIM-URL fest, setzen Sie Authentifizierung auf Bearer-Token und fügen Sie das SCIM-Token als Token-Wert ein. Weisen Sie dann Benutzer und Gruppen im IdP zu und starten Sie die Bereitstellung. Innerhalb weniger Minuten erscheinen Benutzer und Teams in TrueFoundry.

IdP-Gruppen werden zu Teams – das ist der entscheidende Teil

Die meisten SCIM-Anleitungen enden bei der Benutzersynchronisierung. Die Benutzersynchronisierung ist die einfache Hälfte. Der Grund, SCIM auf einer Plattform wie dieser zu nutzen, ist Gruppensynchronisierung, denn in Gruppen findet die Autorisierung statt.

Wenn der Tenant für SCIM konfiguriert ist, wird jede Gruppe, die Ihr IdP überträgt, automatisch zu einem TrueFoundry-Team. Fügen Sie jemanden zur IdP-Gruppe hinzu, tritt er dem Team bei; entfernen Sie ihn, verlässt er es wieder.

Synchronisierte Teams sind in jeder anderen Hinsicht gewöhnliche Teams. Sie können ihnen Ressourcenzugriff gewähren, Rollen auf Tenant-Ebene zuweisen und Identity-Provider-Claim-Mappings hinzufügen.

Formular zur Teamerstellung mit den Feldern „Identity Provider FQN“ und „Claim Value“, die verwendet werden, um einen IdP-Claim einem Team zuzuordnen

Seien Sie präzise bei der Arbeitsteilung, denn es ist leicht, zu viel zu beanspruchen. SCIM entscheidet nicht darüber, was ein Team tun darf – ein Administrator weist dem Team einmalig und bewusst seine Rollen zu. SCIM automatisiert die Mitgliedschaft, und da Berechtigungen an das Team gebunden sind, bedeutet eine aktuelle Mitgliedschaft auch einen aktuell wirksamen Berechtigungssatz. Entwerfen Sie die Autorisierung einmal; überlassen Sie das Tagesgeschäft dem IdP.

Schublade „Zugriff gewähren“ mit einer Auswahl für das Subjekt und den verfügbaren Rollen für eine Ressource

Es gibt eine Namenskonvention, die beachtet werden muss. Der Name der IdP-Gruppe wird zum Teamnamen. Er darf daher nur alphanumerische Zeichen, Bindestriche und Unterstriche enthalten und maximal 36 Zeichenlang sein. Benennen Sie Gruppen im IdP um, bevor Sie die Bereitstellung aktivieren, nicht danach.

Ein Praxisbeispiel: ein Auftragnehmer im ML-Plattform-Team

Hier ist der Lebenszyklus von Anfang bis Ende, wobei die manuellen Schritte markiert sind.

Einmalige Einrichtung (manuell). Ein Administrator erstellt eine IdP-Gruppe namens ml-platform-contractors – kleingeschrieben, mit Bindestrichen, 23 Zeichen, sicher. SCIM überträgt diese, und ein Team mit demselben Namen erscheint in TrueFoundry. Der Administrator gewährt diesem Team die benötigten Berechtigungen: das entsprechende Modellanbieter-Konto, Benutzerzugriff auf zwei MCP-Server, sonst nichts. Das ist das Autorisierungsdesign, einmalig erledigt.

Onboarding (automatisch). Ein Auftragnehmer fängt an. Die HR-Bereitstellung fügt ihn zu ml-platform-contractors hinzu. SCIM erstellt den TrueFoundry-Benutzer und fügt ihn dem Team hinzu. Er meldet sich per SSO an und verfügt exakt über den Zugriff, den das Team hat. Niemand musste ein Ticket erstellen.

TrueFoundry-Anmeldeseite mit der Schaltfläche für das Single Sign-On des konfigurierten Identitätsanbieters

Änderung des Aufgabenbereichs (automatisch). Nach drei Monaten wechselt der Auftragnehmer zu einem anderen Projekt. Jemand entfernt ihn aus ml-platform-contractors und fügt ihn einer anderen Gruppe hinzu. SCIM passt beide Teams an. Sein Zugriff auf den Modellanbieter erlischt mit der Teammitgliedschaft, ohne dass ein Administrator TrueFoundry anfassen musste.

Offboarding (automatisch). Der Vertrag endet. Der IdP-Datensatz wird deaktiviert. SCIM markiert den TrueFoundry-Benutzer als inaktiv, und ein deaktivierter Benutzer wird während des Authentifizierungsvorgangs abgewiesen. Das Konto funktioniert nicht mehr, ohne dass jemand daran denken musste, dass TrueFoundry auf der Liste stand.

Das Einzige, was noch manuell erfolgt. Wenn diesem Auftragnehmer zusätzlich etwas direkt gewährt wurde – zum Beispiel eine einzelne geheime Gruppe außerhalb eines Teams –, bleibt diese Berechtigung bestehen, da sie nie vom IdP stammte. Die Deaktivierung blockiert zwar die Anmeldung, aber der Berechtigungsdatensatz bleibt erhalten, bis ihn jemand entfernt. Planen Sie dies in Ihre Zugriffsüberprüfung ein. Es ist dasselbe Muster, das sich überall zeigt Enterprise-Zugriffskontrolle für MCP: Vererbte und direkte Berechtigungen werden kombiniert; das Entfernen der einen hebt die andere nicht auf.

‍