Was ist SCIM?
SCIM (System for Cross-Domain Identity Management) ist ein offener Standard zur Verwaltung von Benutzeridentitäten über verschiedene Anwendungen und Systeme hinweg. Der Standard ist weit verbreitet – insbesondere in Cloud-Umgebungen – und erleichtert die Anbindung an zentrale IAM-Systeme erheblich.
Wenn Sie sich mit IAM-Lösungen beschäftigen, betreiben Sie wahrscheinlich eine hybride Umgebung aus lokalen und Cloud-basierten Systemen. Zwar wurde SCIM ursprünglich für Cloud-Anwendungen entwickelt, doch es handelt sich um ein allgemeines Protokoll für den Datenaustausch, das also keineswegs ausschließlich für die Cloud gedacht ist. Die Garancy Suite etwa unterstützt sowohl die Migration von Cloud- zu On-Premise-Deployments als auch umgekehrt – SCIM funktioniert in beiden Szenarien reibungslos.
Der große Vorteil: Provisionierung funktioniert mit minimaler Konfiguration. Sobald eine Verbindung hergestellt und autorisiert ist, kann das System Benutzer, Gruppen und andere Ressourcen automatisch bereitstellen sowie deren Attribute und Gruppenmitgliedschaften verwalten.
Doch wodurch wird diese Automatisierung ermöglicht? Werfen wir einen Blick auf das durchdachte Design von SCIM – und darauf, warum in der Praxis trotzdem nicht immer alles reibungslos läuft.
Wie funktioniert SCIM?
Anwendungen, die über SCIM verwaltet werden, heißen Service Provider. Sie stellen eine REST-Schnittstelle bereit, die den SCIM-Standard implementiert. Verbindet sich ein IAM-System wie Azure (Entra ID), Garancy oder Okta mit einer SCIM-fähigen Anwendung, agiert es als Client.
Im SCIM-Kontext bezeichnet man jede verwaltete Entität als Ressource. Der Standard definiert die Ressourcentypen User und Group, jeweils mit einem Satz von Attributen.
:quality(50))
Mit diesem Setup lassen sich bereits viele grundlegende Anwendungsfälle abdecken: Benutzerkonten und Gruppen können erstellt oder gelöscht, Attribute verwaltet (z. B. Passwort-Resets) und über das members-Attribut Gruppenmitgliedschaften vergeben werden, um Berechtigungen zu steuern.
Das beschreibt, wie SCIM 1.1 funktionierte, was aber beschränkt ist: Was wäre zum Beispiel, wenn ein Service Provider ein alias-Attribut für Benutzer einführen oder zusätzliche Ressourcentypen wie Entitlements, Password Policies, Roles oder Devices verwalten möchte?
SCIM 1.1-Clients können solche benutzerdefinierten Attribute und Ressourcen nicht automatisch verarbeiten – sie erfordern manuelle Konfiguration oder providerspezifische Anpassungen.
SCIM 2.0 – Dynamische Erkennung und flexible Schemas
SCIM 2.0 beseitigt viele dieser Einschränkungen durch sogenannte Service-Discovery-Endpunkte, über die ein Service Provider seine Fähigkeiten offenlegen kann. Über einen dieser Endpunkte können Service-Provider eigene Ressourcentypen definieren und über einen weiteren für jede Ressource die unterstützten Attribute festlegen.
:quality(50))
Je nach Service Provider können verschiedene Ressourcentypen vorkommen, z. B. Account, Authorization, Device, Entitlement, Password Policy, Role und viele mehr
Die Attribute eines Ressourcentyps lassen sich in drei Kategorien einteilen:
Common-Attribute und das schemas-Attribut – vom SCIM-Standard definiert, in allen Ressourcen automatisch enthalten
Base-Attribute – in dem Schema definiert, das für den Ressoucentyp als Base-Schema festgelegt wurde
Extension-Attribute – über Schema-Erweiterungen eingebunden
Common-Attribute und das schemas-Attribut sind fest definiert und unveränderbar. Jeder Ressourcentyp verweist auf ein Base-Schema, das unter einem separaten Endpunkt verfügbar ist und von mehreren Ressourcentypen genutzt werden kann.
Base-Schemas können ergänzt werden, indem andere Schemas als Schema-Extensions referenziert werden, die dann Extension-Attribute hinzufügen. So bleiben gleichnamige Attribute aus verschiedenen Schemas stets sauber getrennt.
Wie weit reicht die SCIM-Unterstützung in der Praxis?
Auch wenn SCIM theoretisch feingranulare IAM-Kontrolle verspricht, ist die Unterstützung in realen Implementierungen oft unzureichend. Die Angabe, dass SCIM unterstützt wird, sagt noch nichts über konkrete Funktionen oder Kompatibilität aus.
Der SCIM-Standard (RFC 7643 und RFC 7644) ist bewusst offen gehalten: Er erlaubt alles – von minimalem Lesezugriff auf wenige Ressourcen bis hin zu vollständiger Verwaltung aller Attribute und Einstellungen.
Unglücklicherweise ist RFC 7643 an vielen Stellen ungenau und hat viele Errata. Dies führt zu unterschiedlichen Interpretationen und Inkompatibilitäten zwischen Implementierungen. Trotzdem haben sich einige gemeinsame Muster etabliert – mehr dazu in unserem Beitrag zur manuellen SCIM 2.0-Konfiguration.
Typische SCIM-Implementierungen
Nahezu alle Service Provider implementieren die Ressourcen User und Group mit den Standard-Core-Schemas, häufig erweitert durch das Enterprise User Schema. Gruppenzugehörigkeiten werden in der Regel über das members-Attribut in Gruppenobjekten verwaltet – wie es der Standard vorsieht.
Schemas werden üblicherweise angepasst: Nicht unterstützte Attribute werden entfernt, Eigenschaften wie „required“ oder „read-only“ werden angepasst, zusätzliche Attribute werden meist über Schema-Erweiterungen eingebunden und seltener direkt in die Core-Schemas integriert.
Ein typischer SCIM-Service-Provider (wie Atlassian) unterstützt die Standardressourcen User und Group und ca. 40 Attribute und Unterattribute. Große Anbieter wie SAP Identity Directory Services (IdDS) bieten mehr Ressourcen und providerspezifische Schema-Erweiterungen – mit über 250 Attributen und Unterattributen.
Intelligenter SCIM-Konnektor in Garancy
Garancys intelligenter SCIM-Konnektor, verfügbar ab Version 26.1, verarbeitet sämtliche Ressourcentypen und Schema-Informationen automatisch – und bietet so maximale Flexibilität bei minimalem Konfigurationsaufwand.
Das funktioniert am besten, wenn Service Provider exakte Schema-Daten bereitstellen. Bei vielen ist das der Fall, sodass Garancy alle verfügbaren Attribute mit minimalem Konfigurationsaufwand verwalten kann. Der Konnektor verarbeitet unterschiedliche SCIM-Interpretationen und toleriert kleinere Schema-Fehler, die teilweise aufgrund von Errata in den Schema-Definitionen in RFC 7643 häufig auftreten. Da RFCs nicht aktualisiert werden, müssen diese bekannten Fehler manuell korrigiert werden. Die korrigierten Core-Schemas können im SCIM 2.0 Schema Checker heruntergeladen werden.
Einige Service Provider haben jedoch erhebliche Schema-Probleme, die die automatische Erkennung einschränken. Der Konnektor von Garancy behebt derartige Probleme, indem er die Antworten der Anbieter dynamisch korrigiert und Anfragen anpasst. Dies lässt sich über Velocity-Templates mit minimalem Programmieraufwand konfigurieren. Der SCIM 2.0 Schema Checker hilft bei der Überprüfung von Schema-Definitionen und der Identifikation von Problemen, die behoben werden müssen.