Blog-Artikel

Frau schaut auf schwarze Wand mit Connection-Symbolen
Was ist SCIM und wie funktioniert es in der Praxis?

Die Verwaltung digitaler Identitäten über mehrere Systeme hinweg ist ein zentraler Bestandteil moderner IT-Sicherheit – und der Standard SCIM (System for Cross-Domain Identity Management) hat sich hierbei als Schlüsseltechnologie etabliert. SCIM wurde entwickelt, um den Austausch von Benutzer- und Gruppendaten zwischen Identity Providern und Service-Anwendungen zu vereinfachen, und wird heute breit eingesetzt – sowohl in Cloud- als auch in hybriden Umgebungen. Doch obwohl SCIM nahtlose Integration und automatisierte Bereitstellung verspricht, ist die Realität oft komplexer. In diesem Artikel erklären wir, wie SCIM funktioniert, wo seine Grenzen liegen und wie Garancy SCIM nutzt, um eine robuste und flexible Identity Governance zu ermöglichen.

Mehr erfahren

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.

User and Group resources defined by SCIM standard

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.

SCIM Resource Types

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.

Mehr erfahren

Autor

Dr. Matthias Winter
Software Architect

Tags

IAM

Teilen

Weitere Ressourcen

Blog-Artikel
Computer monitor with code

Wie man eine SCIM 2.0 Server-Konfiguration von Hand erstellt

Die Service-Discovery-Endpunkte eines SCIM 2.0 Servers manuell einzurichten kann zunächst einschüchternd wirken, muss es aber nicht sein. In dieser Anleitung führen wir Sie Schritt für Schritt durch den Prozess, wie Sie auf einfachem Weg die technischen Definitionen für Ihre ServiceProviderConfig-, ResourceTypes- und Schemas-Endpunkte passend zu Ihrer Anwendung erstellen. Und das Beste: Sie können Ihre Konfiguration mit unserem SCIM 2.0 Schema Checker validieren, Fehler frühzeitig erkennen und somit vollständige Konformität mit der SCIM-Spezifikation sicherstellen.
Blog-Artikel
blogartikel_kubernetes.jpg

Workload Automation in Kubernetes: Brückentechnologie für moderne Container-Orchestrierung

Wie sich klassische Workload Automation mit modernen Kubernetes-Umgebungen verbinden lässt: Ein Blick auf IBM Workload Scheduler, den Beta Systems Cloud Connector und die Rolle von Ingress, Sidecars und Git-basierten Job-Definitionen in der IT-Automatisierung containerisierter Unternehmens-IT.
Blog-Artikel
blogpost_migration-ohne-reue.jpg

Migration ohne Reue: So machen Sie Ihre Automatisierungsstrategie zukunftssicher

In einer zunehmend datengetriebenen IT-Welt steigen die Anforderungen an Unternehmenssysteme rapide. Agilität, Skalierbarkeit und die Integration neuer Technologien wie KI, Cloud-Infrastrukturen oder Observability-Plattformen verändern die Anforderungen an moderne Workload Automation (WLA). Dabei stellt sich vielen Unternehmen eine zentrale Frage: Sollten wir unsere bestehende WLA-Plattform modernisieren?