SCIM und SAML: Fachanwendungen an ein IAM anbinden
Was ist SCIM, und warum kostet die Anbindung Aufwand?
SCIM, ausgeschrieben System for Cross-domain Identity Management, ist ein Standard, über den zwei Systeme Benutzerkonten abgleichen: Das eine meldet Eintritte, Wechsel und Austritte, das andere zieht nach.
Die IAM-Anbindung einer Fachanwendung verbindet eine einzelne Anwendung mit dem zentralen Identitäts- und Berechtigungsmanagement-System einer Organisation. Über SCIM werden Benutzerkonten und Rechte automatisch angelegt, geändert und entzogen, über SAML oder OpenID Connect läuft die Anmeldung. Ohne diese Anbindung bleibt die Anwendung eine Insel mit eigener Benutzerverwaltung.
Die Bitkom-Studie Wirtschaftsschutz 2026 zeigt, was das kostet: 55 Prozent der geschädigten Unternehmen nennen ein unzureichendes Identitäts- und Zugriffsmanagement als Grund dafür, dass ein Angriff überhaupt zum Schaden wurde. Häufiger genannt werden nur Fehlkonfigurationen mit 57 und eine schwache Vorfallerkennung mit 59 Prozent.
Was der Identity Provider übernimmt
Der Identity Provider ist der Teil der IAM-Lösung, in dem die digitalen Identitäten aller Beschäftigten liegen, meist ein Verzeichnisdienst oder eine Cloud-Plattform. Er beantwortet zwei Fragen: um welche Person es sich handelt und ob sie hier hinein darf. Ein KI-Dienst ist keine Person und fällt aus diesem Schema heraus, braucht aber eigene, begrenzte Rechte, weshalb KI-Sicherheit hier eine eigene Frage aufmacht. Die Fachanwendung behält dagegen alles, was nur sie kennt, also eigene Rollen, Freigabestufen und Mandanten. Deshalb ersetzt eine IAM-Integration die Rechteverwaltung in der Anwendung nie vollständig. Welche Nachweise trotzdem aus der Anwendung selbst kommen müssen, klärt der Abschnitt zur Prüfung der Zugriffsrechte.
Warum Identitäten an mehreren Orten liegen
Kaum ein Unternehmen hält seine Identitäten an einer einzigen Stelle. 38 Prozent der cloudnutzenden Unternehmen beziehen Dienste von mehreren Anbietern, 34 Prozent betreiben eine Mischung aus Cloud und eigenem Rechenzentrum, so der Bitkom Cloud Report 2026. Jede dieser Umgebungen bringt ihre eigene Kontenverwaltung mit, und jede zusätzliche Insel verlängert die Liste vergessener Konten. Ein IT-Sicherheitsmanagement muss diese Streuung kennen, bevor es Maßnahmen festlegt.
Typische Orte, an denen Konten getrennt voneinander entstehen:
- Verzeichnisdienst im eigenen Rechenzentrum
- Cloud-Plattform für Postfächer und Dateien
- Branchensoftware mit eigener Benutzertabelle
- Fachportale von Kammern, Kassen oder Behörden
- Werkzeuge, die einzelne Abteilungen selbst beschafft haben
Welche Standards eine IAM-Lösung erwartet
Drei Standards deckt praktisch jede IAM-Lösung ab, und an ihnen entscheidet sich, ob eine Anbindung eine Konfiguration oder ein Entwicklungsauftrag ist. Spricht eine Anwendung keinen davon, wird die IAM-Schnittstelle ein Fall für die Schnittstellenentwicklung.
SCIM-Provisioning für Konten und Rechte
Die Provisionierung ist der unspektakuläre, aber teure Teil der Anbindung. Sie sorgt dafür, dass ein Konto entsteht, sobald jemand anfängt, und verschwindet, sobald jemand geht. Genau dafür ist SCIM-Provisioning gebaut, und die Automatik wirkt erst, wenn beide Seiten denselben Standard sprechen.
Was ein SCIM-Anschluss im Alltag übernimmt:
- Konten anlegen, wenn im Personalsystem ein Eintritt erfasst wird
- Gruppen und Rollen aus dem Verzeichnis übernehmen
- Konten beim Austritt sperren statt löschen
- Änderungen protokollieren, damit sie später belegbar sind
Was SCIM nicht abdeckt
SCIM überträgt Konten und Gruppen, nicht die Bedeutung dieser Gruppen. Welche Rechte hinter einer Rolle stehen, entscheidet die Anwendung, und dieses Modell muss vorher entworfen sein. Der Rollenschnitt und seine regelmäßige Bestätigung gehören ins Berechtigungsmanagement, nicht in die Schnittstelle. Ohne dieses Modell synchronisiert die Anbindung leere Hüllen: Die Konten stimmen, die Rechte dahinter bleiben Handarbeit.
SAML-SSO und die Anmeldung am Identity Provider
Während SCIM die Konten pflegt, regelt SAML-SSO die Anmeldung, also das Single Sign-On über alle angeschlossenen Anwendungen. Die Anwendung fragt beim Identity Provider nach, ob eine Sitzung gültig ist, und verlässt sich auf dessen Antwort. Das BSI führt ihn im Baustein ORP.4 als zentralen Authentisierungsdienst. Die geprüften Faktoren, vom Passwort bis zur zweiten Bestätigung, bleiben Sache der Authentifizierung in Unternehmenssoftware. Fällt der Identity Provider aus, meldet sich niemand mehr an, und dieser Fall gehört vor dem Start durchdacht.
LDAP-Anbindung und Active-Directory-Anbindung
Der älteste Weg ist auch der häufigste. Bei einer LDAP-Anbindung fragt die Anwendung ein Verzeichnis direkt ab, ob ein Konto existiert und das Passwort stimmt. Das Lightweight Directory Access Protocol beherrschen selbst betagte Anwendungen, und eine Active-Directory-Anbindung läuft technisch genauso. Zum Provisionieren taugt dieser Weg nicht: Er beantwortet Anfragen, er schickt keine Änderungen los. Für die IAM-Lösung bleibt die Anwendung sichtbar, aber nicht steuerbar.
Wenn die Fachanwendung kein SCIM spricht
Im Mittelstand ist das der Normalfall: Die Cloud-Dienste hängen längst am Single Sign-On, die Branchensoftware aus dem Jahr 2014 dagegen kennt weder SCIM noch SAML-SSO. Gleichzeitig liegen dort die geschäftskritischen Daten.
Wer baut die Anbindung ohne Standard?
Fehlt der Standard, entsteht die IAM-Schnittstelle als eigenes Stück Software. Sie liest die Personal- oder Verzeichnisdaten, übersetzt sie in das Format der Anwendung und schreibt sie über deren Datenbank oder Programmierschnittstelle. Das ist keine Einstellung, sondern eine Entwicklungsleistung mit Test, Abnahme und Pflege. Entscheidend für die Kalkulation ist deshalb nicht der Standard, sondern ob die Anwendung eine dokumentierte Schnittstelle mitbringt.
Was den Aufwand tatsächlich treibt
Der Preisunterschied zwischen zwei ähnlichen Projekten liegt selten am IAM. Er liegt an dem, was die Anwendung auf ihrer Seite zulässt, und daran, wie viele Sonderfälle die Organisation kennt. Diese Punkte treiben den Aufwand am stärksten:
- Dokumentierte Programmierschnittstelle vorhanden oder nicht
- Zahl der Rollen, die abgebildet werden müssen
- Mehrfachrollen, Vertretungen und befristete Zugänge
- Externe wie Praktikanten, Leihkräfte und Dienstleister
- Pflegeaufwand, wenn der Identity Provider ein Update erhält
SAML-SSO in einer Altanwendung ergänzen
Bei der Anmeldung ist die Nachrüstung einfacher, weil es Bibliotheken für SAML und OpenID Connect für alle verbreiteten Sprachen gibt. Der Aufwand steckt nicht im Protokoll, sondern in der Anwendung: Sie muss ihre eigene Anmeldemaske abgeben. Bei gewachsenen Anwendungen sitzt diese Logik oft an mehreren Stellen im Code. Eine SSO-Integration ist deshalb selten nur ein Anmeldethema, sondern auch eine Aufräumarbeit.
Anbindung planen, abnehmen und nachweisen
Der Zeitpunkt entscheidet über den Preis. Bei einer Neuentwicklung ist die SAML-SSO-Anbindung eine Zeile im Lastenheft, im Bestand ist sie ein eigenes Vorhaben mit eigenem Budget. Deshalb gehört die Frage in die Beschaffung und nicht in den Betrieb.
Eintritt, Wechsel und Austritt im Betrieb
Diese drei Ereignisse, im Fachjargon Joiner Mover Leaver, sind der eigentliche Grund für die ganze Übung. Der Eintritt fällt selten auf, weil eine fehlende Berechtigung sofort gemeldet wird. Der Wechsel und der Austritt fallen nicht auf, weil ein zu viel gebliebenes Recht niemandem im Weg steht. Genau diese stillen Fälle lassen Konten Jahre überdauern. Eine funktionierende Provisionierung dreht die Beweislast: Das Personalsystem löst den Entzug aus, nicht die Fachabteilung.
Was bei einer Prüfung vorzulegen ist
Bei einer Prüfung interessiert die Schnittstelle niemanden. Gefragt ist der Nachweis, dass Rechte tatsächlich verschwunden sind, mit Zeitpunkt und auslösendem Vorgang. Art. 32 Abs. 1 lit. b DSGVO verlangt geeignete Maßnahmen für Vertraulichkeit und Integrität, Anhang A der ISO/IEC 27001:2022 führt eigene Controls zur Zugangssteuerung, und das BSI beschreibt in ORP.4 die Dokumentation der Benutzerkennungen und Rechteprofile. Keine dieser Vorgaben schreibt ein Produkt vor, alle drei verlangen einen belegbaren Ablauf.
Was eine Prüfung typischerweise sehen will:
❗ Liste aller Konten je Anwendung mit Zuordnung zu einer Person
❗ Protokoll der Rechteänderungen mit Zeitstempel
❗ Belegter Entzug für Austritte der letzten Monate
❗ Beschreibung, welche Rechte hinter welcher Rolle stehen
❗ Verfahren für privilegierte Konten und Dienstkonten
TenMedia entwickelt Individualsoftware, die den Anschluss an ein bestehendes Identitäts- und Berechtigungsmanagement-System von Anfang an mitbringt, und rüstet ihn im Bestand nach. In der mandantenfähigen Plattform für Betreuungsdienste trennt ein feingranulares Rechte- und Rollenkonzept schützenswerte Gesundheitsdaten. Für Protokollierung und Dokumentation gilt dabei die IT-Compliance.
Hinweis: Dieser Beitrag dient der allgemeinen Information und stellt keine Rechtsberatung dar. Für verbindliche Auskünfte zu regulatorischen Anforderungen empfehlen wir die Konsultation einer spezialisierten Rechtsberatung.