Identity Provisioning mit SAP Identity Provisioning Service (IPS) – Konzepte, Regeln und Best Practices
Source/Target-Prinzip, Transformation Rules und Monitoring im SAP IP
Identity Provisioning ist eine der zentralen Disziplinen moderner Identity-&-Access-Management-Architekturen. Besonders in hybriden SAP-Landschaften mit HR-Systemen, Directories, Cloud-Plattformen und Fachanwendungen entscheidet ein sauberes Provisioning-Modell über Datenqualität, Sicherheit und Betriebsstabilität.
Der SAP Identity Provisioning Service (IPS) stellt hierfür ein flexibles Framework bereit, das auf klaren Source-/Target-Beziehungen, regelbasierter Transformation und automatisiertem Monitoring basiert. Dieser Beitrag zeigt, wie das Source/Target-Prinzip funktioniert, welche Transformation Rules sich in der Praxis bewährt haben und worauf es bei Betrieb, Änderungen und Fehleranalyse ankommt.
Dieser Beitrag zeigt, wie Unternehmen mit dem SAP Identity Provisioning Service (IPS) eine skalierbare IAM-Strategie umsetzen, die durch das Source/Target-Prinzip und ein striktes Attribut-Ownership-Modell Datenkonflikte effizient vermeidet.
Identity Provisioning
Das Source/Target-Prinzip
Im SAP Identity Provisioning Service ist das Source/Target-Prinzip das Grundmodell jedes Provisioning-Flows. Es legt fest, woher Identitätsdaten kommen (Source), wohin sie geschrieben werden (Target) und umfasst klare Verantwortlichkeiten.
In IPS wird ein Job immer als Datenfluss zwischen Source System und Target Systemen konfiguriert. Ein Job ist eine ausführbare Provisioning-Einheit, die:
- Daten aus genau einem Source System liest
- diese Daten nach definierten Regeln verarbeitet
- sie in ein oder auch mehrere Target Systeme schreibt
Typische Kombinationen:
- SuccessFactors (Source) → IAS (Target): HR als führende Quelle für Stammdaten, IAS als Userstore für Authentifizierung.
- Entra/AD (Source) → IAS (Target): Corporate Directory liefert Accounts und Gruppen.
- IAS (Source) → BTP-App (Target): IAS-User/Groups werden in eine Anwendung oder einen BTP-Service gespiegelt.
In hybriden Landschaften existieren dieselben Attribute in mehreren Systemen: Name, E-Mail, Login, Organisation, Rolle, Status, Technische Flags, Gruppen etc.
Wichtig ist daher die Entscheidung: Welche Quelle ist „Master“ für welche ?
Ein Fehler, den wir häufig sehen, ist das Vermischen von Verantwortlichkeiten (z. B. HR überschreibt technische Logins oder E-Mail-Adressen aus dem Directory).
Bewährt hat sich ein klares Attribut-Ownership-Modell. Ein Attribut-Ownership-Modell beschreibt, welches System für welches Benutzerattribut fachlich und technisch führend ist und damit auch, wer dieses Attribut setzen, ändern oder überschreiben darf. Zum Beispiel:
- HR: Name, Org-Info, Manager, Employment Status
- Directory: Login, Mail, Gruppenmitgliedschaften, technische Flags
- Lokale Ergänzungen: App-spezifische Attribute in IAS (nur wenn sauber abgegrenzt)
Grundlegende Transformation Rules
Transformation Rules dienen dazu, eingehende Daten in das Zielschema zu mappen und zu bereinigen. In Projekten sehen wir immer wieder diese Basistypen:
- Quelle userName → Ziel loginName
- Quelle mail → Ziel emails[0].value (abhängig vom
- Zielschema)
- Kleinschreibung von Logins
- Entfernen von Leerzeichen, Ersetzen von Sonderzeichen, Festlegen von Standards
- Ableiten von displayName aus Vorname/Nachname
- Setzen eines Default-Werts, wenn Quelle leer ist
- Nur aktive Mitarbeiter provisionieren
- Ausschluss bestimmter User-Typen (z. B. Praktikanten, technische Konten), wenn fachlich erforderlich
- Gruppen aus Directory → Zielgruppen in IAS/BTP
- Regelbasiert: „Wenn Department = X, dann Gruppe Y“
Transformation & Monitoring
Anpassung von Regeln und Jobs
In der Realität ändern sich Regeln häufiger als gedacht: Neue Org-Strukturen, neue Anwendungen, zusätzliche Attribute, M&A-Szenarien. Erfolgsfaktoren:
- Versions-/Änderungsprozess: Regeln nicht „live“ im Produktivsystem herumprobieren (SAP liefert immer 2 Cloud Identity Instanzen aus, die man auch nutzen sollte), sondern über Test → Prod transportieren (mindestens dokumentiert, ideal mit klaren Freigaben).
- Kleine, verständliche Regeln statt Monolithen: leichter wartbar und debuggbar.
- Implementierung von Security Gates wie Thresholds für Löschungen, etc.
Testdaten-Sets: repräsentative User (aktiv/inaktiv, Sonderzeichen, mehrere E-Mails, Externe etc.) für Regressionstests.Monitoring & Debugging – was sich bewährt
Ein stabiler Betrieb hängt stark davon ab, ob man Probleme schnell erkennt und reproduzierbar behebt. Der Cloud ALM kann hierfür eingebunden werden, zudem bieten die Cloud Identity Services APIs wie u.a. SCIM für die Anbindung beliebiger Tools für Monitoring/Auditing Zwecke an.
Praktische Monitoring-Ansätze:
- Job-Status & Laufzeiten beobachten: plötzliche Laufzeitsteigerungen sind oft ein Indikator für Quellprobleme oder „Explosions“-Effekte durch Gruppenzuordnungen.
- Delta vs. Full Provisioning: Deltas sind effizient, aber Full Runs helfen bei Dateninkonsistenzen. Ein geplanter Full Run in sinnvollen Intervallen (oder bei Änderungen) kann Stabilität erhöhen.
- Fehlerklassifizierung:
- Auth/Connectivity (Credentials, Zertifikate, Netzwerk)
- Schema/Mapping (falsche Attribute, unerwartete Datentypen)
- Business Rules (Filter greift falsch, leere Pflichtfelder)
- Target Constraints (Duplikate, Namenskonflikte)
Debugging-Tipps aus Projekten:
- Immer zuerst prüfen: Welche Quelle hat welchen Wert geliefert? Oft liegt der Fehler nicht in der Regel, sondern in der Quelle, dennoch sollte man sowohl imSource- als auch im Target-Mapping den Debugging Modus nutzen.
- Eindeutige Mappings anhand der Global User Id und damit Vermeidung von Duplikaten. Bei Gruppen: vermeiden, dass Gruppen/Assignments „kreisen“ (z. B. Zielsystem schreibt zurück in Quelle).
Fazit
Ein stabiles und wartbares Identity Provisioning mit SAP IPS steht und fällt mit klaren Verantwortlichkeiten. Das konsequente Source/Target-Prinzip, ein sauberes Attribut-Ownership-Modell und übersichtliche Transformation Rules verhindern Datenkonflikte und ungewollte Überschreibungen.
Ebenso wichtig ist der Blick auf den Betrieb: Versionierung, Tests, Security Gates und ein belastbares Monitoring sind keine „Nice-to-haves“, sondern essenzielle Erfolgsfaktoren. Wer Provisioning als lebenden Prozess versteht und Regeln strukturiert weiterentwickelt, schafft die Basis für sichere, skalierbare und zukunftsfähige IAM-Architekturen
Sie möchten mehr erfahren?
Wir beraten Sie gerne. Nehmen Sie jetzt Kontakt zu uns auf.
Das könnte Sie ebenfalls interessieren