SCIM (System for Cross-domain Identity Management) ist ein offener Standard, der beschreibt, wie ein zentrales Benutzerverzeichnis (der Identity Provider, z. B. Microsoft Entra ID oder Okta) die Benutzer- und Gruppen-Daten in nachgelagerten Anwendungen automatisch synchron hält. Statt jede Anwendung einzeln zu pflegen, meldet das Verzeichnis neue Mitarbeiter, geänderte Attribute und Austritte über standardisierte Web-Aufrufe an die Zielanwendung. SCIM in der Version 2.0 ist in den offiziellen Internet-Standards IETF-RFC 7643 (Datenformat) und 7644 (Ablauf der Aufrufe) festgelegt.
Was ist SCIM?
SCIM ist ein Protokoll für die Provisionierung, also die Frage, welche Nutzer und Gruppen in einer Zielanwendung überhaupt existieren und welche Merkmale (Name, E-Mail, Aktiv-Status) sie tragen. Den führenden Datenbestand hält ein zentrales Identitätssystem (Identity Provider, kurz IdP), typischerweise Microsoft Entra ID, Okta oder Google Workspace. Dieses System schickt über HTTPS strukturierte Meldungen im Format JSON (ein maschinenlesbares Textformat) an eine Adresse in der Zielanwendung, den sogenannten SCIM-Endpunkt. Die Meldungen folgen einem festen Feldkatalog mit Angaben wie Benutzername, Anzeigename, E-Mail-Adressen, Aktiv-Kennzeichen und Gruppenzugehörigkeit.
Damit grenzt SCIM sich klar von SAML und OIDC ab: SAML und OIDC sind Authentifizierungsprotokolle und beantworten beim Login, ob ein User sich legitim ausweisen kann. SCIM beantwortet die vorgelagerte Frage, ob dieser User in der Zielanwendung überhaupt bekannt ist und welche Gruppen er trägt. In der Regel werden beide Wege kombiniert: SCIM provisioniert User und Gruppen, SAML oder OIDC authentifiziert sie beim Zugriff.
| Aspekt | SCIM | SAML / OIDC |
|---|---|---|
| Zweck | Provisionierung von User- und Group-Objekten | Authentifizierung beim Login |
| Frage | Wer existiert in der Zielanwendung? | Wer darf gerade rein? |
| Transport | REST/JSON über HTTPS | Browser-Redirects, Tokens |
| Auslösung | Ereignisgetrieben oder zyklisch im IdP | Beim Login-Versuch des Users |
Wie SCIM Identitäten provisioniert
Der typische Ablauf beginnt im Identity Provider. Wird einem User dort eine Gruppe zugewiesen, die für eine Zielanwendung freigeschaltet ist, ruft der SCIM-Client den SCIM-Endpoint der Anwendung auf und legt den User per POST /Users an. Änderungen an Attributen, Gruppenmitgliedschaften oder dem Aktiv-Status spiegelt der IdP über PATCH- oder PUT-Aufrufe nach. Wird der User im IdP deaktiviert oder die Gruppenzuweisung entzogen, setzt der SCIM-Client active: false oder entfernt die Mitgliedschaft.
Gruppen werden parallel über /Groups gepflegt; Mitgliedschaften erscheinen als members-Array im Group-Objekt. Verschachtelte Gruppen sind in SCIM 2.0 nicht durchgängig standardisiert: Manche Zielanwendungen lösen nur die direkten Mitglieder einer SCIM-Gruppe auf und ignorieren transitiv enthaltene Untergruppen. Dieselbe Einschränkung gilt häufig für Dynamic Groups im IdP, deren Mitgliedschaft sich aus Regeln statt aus expliziten Zuweisungen ergibt.
Just-in-Time-Provisioning (JIT) ist eine Variante: Der User wird erst beim ersten SAML- oder OIDC-Login der Zielanwendung aus den Assertions erzeugt, statt vorab per SCIM. JIT deckt den Create-Schritt ab. Gruppen-Synchronisation, laufende Attribut-Updates und Deaktivierungen brauchen weiterhin einen SCIM-Kanal.
SCIM in Databricks und Unity Catalog
In Databricks läuft SCIM auf der Account-Ebene. Der Identity Provider provisioniert User und Gruppen einmal in den Databricks-Account; einzelne Workspaces beziehen daraus über Identity Federation die für sie freigegebenen Identitäten. Unity Catalog arbeitet ausschließlich mit den Gruppen, die auf Account-Ebene existieren. GRANT-Statements vergeben Berechtigungen auf Catalogs, Schemas und Tabellen typischerweise an SCIM-provisionierte Gruppen statt an einzelne User. Damit ist der SCIM-Kanal der zentrale Steuerpunkt: Wer aus einer Gruppe entfernt wird, verliert über den nächsten Sync auch die zugehörigen Unity-Catalog-Rechte.
Im Betrieb ergeben sich aus diesem Modell wiederkehrende Stolpersteine. Verschachtelte Gruppen aus Entra ID oder Okta landen oft nur flach im Databricks-Account; geplante Berechtigungen über die Untergruppe greifen dann nicht. Deaktivierte User behalten bestehende Personal Access Tokens, bis diese ablaufen oder explizit widerrufen werden. Der Login ist blockiert, ein Token-basierter Job kann aber weiterlaufen. Fehlende oder verzögerte SCIM-Updates blockieren außerdem Ownership-Wechsel: Eine Tabelle oder ein Job lässt sich nicht auf einen User übertragen, den der Account noch nicht kennt.
SCIM (System for Cross-domain Identity Management) im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.