SAP Cloud Identity Services in hybriden Systemlandschaften – IAS & IPS Best Practices
Nutzung und Anpassung der SAP Cloud Identity Services in hybriden Systemlandschaften
Hybride Systemlandschaften sind in SAP-Projekten längst die Norm: SAP S/4HANA (On-Prem oder Private Cloud) läuft neben SAP BTP-Services, SaaS-Lösungen wie SuccessFactors/Ariba/Concur, dezidierten IAM-Tools und zusätzlich Microsoft Entra (Azure AD) oder andere zentrale Identity Provider.
In diesem Setup entscheidet ein sauberer Identity-Ansatz über:
- Benutzererlebnis (einheitliches Login-Erlebnis durch SSO),
- Sicherheit (Conditional Access für die kontextbasierte Zugriffskontrolle, MFA zum Schutz vor dem unberechtigten Zugriff) und
- Betrieb (Automatisierung und Konsistenz beim Provisioning , Transparenz und Stabilität beim Monitoring, Nachvollziehbarkeit für Audits).
Der Beitrag zeigt, wie IAS und IPS in hybriden Landschaften zusammenspielen, welche Einsatzmuster sich bewährt haben und wie man Provisioning, Transformation, Monitoring und SSO sauber aufsetzt.
Aufgaben des Identity Authentication Services
Der SAP Identity Authentication Service (IAS) ist die zentrale Komponente für Authentifizierung und Single Sign-On in SAP-Cloud- und hybriden Landschaften. Er stellt standardisierte Authentifizierungsprotokolle wie SAML 2.0 und OpenID Connect (OIDC) bereit und fungiert häufig als Identity Hub zwischen Corporate Identity Providern und SAP-Anwendungen. Diese Konfiguration wird auch als Proxy Konfiguration bezeichnet und als Best Practice-Ansatz von SAP empfohlen.
IAS übernimmt zentrale Funktionen für Authentifizierung:
- Trust-Beziehungen zu Identity Providern
- Authentifizierungsrichtlinien
- Conditional Authentication (z. B. MFA, kontextabhängige Zugriffskontrollen)
Aufgaben des Identity Provisioning Services
Der SAP Identity Provisioning Service (IPS) ist für die automatisierte Versorgung von Identitäten, Attributen und Gruppen zwischen Systemen verantwortlich. Er verbindet definierte Source- und Target-Systeme über gerichtete Provisioning-Jobs und übernimmt dabei Mapping, Transformation, Filterung und Synchronisation von Benutzer- und Gruppendaten.
IPS unterstützt Joiner-Mover-Leaver-Prozesse und sorgt dafür, dass Identitätsdaten konsistent, aktuell und regelbasiert in Zielsystemen wie IAS, SAP Cloud und on-premise Systemen, SAP BTP oder SaaS-Anwendungen verfügbar sind.
Das IPS ermöglicht zudem die Real-Time Provisionierung der User aus dem SuccessFactors heraus und wird in zukünftigen, bereits angekündigten Ausbaustufen auch ein event-basiertes Provisioning für weitere Systeme unterstützen. Dabei fungiert IPS als Integrations- und Transformationsschicht, nicht als Directory, und setzt definierte Attribut-Ownership-Modelle technisch um.
Architektur & typische Einsatzmuster
Zusammenspiel von IAS und IPS
IAS ist der zentrale Baustein für Authentifizierung und SSO, während IPS für Identitäten- und Berechtigungsdatenfluss (User/Group/Attributes) zuständig ist. In hybriden Landschaften entstehen daraus verschiedene typische Muster hinsichtlich ihres Zusammenspiels:
Viele Organisationen betreiben bereits einen eigenen IdP, z.B. Entra als führenden Identity Provider. IAS wird dann als Proxy/Identity Hub eingesetzt:
- Corporate IdP → IAS (Trust) → SAP Cloud Apps / BTP
- Vorteil: Einheitliche Konfiguration für SAP-Anwendungen, SAP-spezifische Features (z. B. Conditional Authentication im IAS-Kontext), konsistente Claims.
Gerade bei BTP-zentrierten Architekturen kann IAS selbst „primary“ sein, insbesondere wenn:
- SAP-Anwendungen dominieren,
- ein lokaler Userstore nötig ist (Partner, Externe, Testnutzer),
- feinere Steuerung pro Anwendung gewünscht ist.
IPS verbindet Quellen und Ziele nach dem Prinzip „Source → Target“:
- Source: HR (SuccessFactors), Corporate Directory (Entra/AD), IAM-Systeme
- Targets: IAS (Userstore), SAP BTP / XSUAA-Umfelder, SAP Analytics Cloud, Ariba/Concur (je nach Konnektorlandschaft)
- Nutzen: Entkopplung der Systeme, einheitliche Transformationslogik, nachvollziehbare Provisioning-Jobs
Wo stiften IAS/IPS in hybriden Landschaften den größten Nutzen?
- SSO-Konsolidierung: Ein Einstiegspunkt für SAP-Anwendungen statt viele, inkonsistente Trusts.
- Sauberes Joiner-Mover-Leaver:
Joiner–Mover–Leaver (JML) bezeichnet ein Standardkonzept im Identity- und Access-Management, mit dem der Lebenszyklus eines Benutzers innerhalb einer Organisation beschrieben wird. Ziel ist es, Benutzerkonten und Berechtigungen automatisiert, konsistent und revisionssicher zu steuern.
Automatisierte Benutzeranlage/Änderung/Deprovisionierung über IPS. - Attribut- und Rollen-/Gruppen-Harmonisierung: Transformation Rules, um heterogene Quellen in ein Zielmodell zu überführen.
- Betrieb und Compliance: Monitoring, nachvollziehbare Laufprotokolle, weniger manuelle Pflege.
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:
- Mapping / Rename
- Quelle userName → Ziel loginName
- Quelle mail → Ziel emails[0].value (abhängig vom Zielschema)
- Normalisierung
- Kleinschreibung von Logins
- Entfernen von Leerzeichen, Ersetzen von Sonderzeichen, Festlegen von Standards
- Enrichment
- Ableiten von displayName aus Vorname/Nachname
- Setzen eines Default-Werts, wenn Quelle leer ist
- Filtering
- Nur aktive Mitarbeiter provisionieren
- Ausschluss bestimmter User-Typen (z. B. Praktikanten, technische Konten), wenn fachlich erforderlich
- Group-/Role-Zuordnung
- 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.
Testdatensets
Testdatensets: 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).
Identity Authentication
SSO-Szenarien (typisch in hybriden Setups)
- SAML 2.0 ist weiterhin Standard für viele SAP-Anwendungen.
- OIDC gewinnt in modernen BTP- und Custom-App-Szenarien an Bedeutung.
Bewährtes Muster: Corporate IdP → IAS → App
IAS übernimmt dabei:
- Token-/Assertion-Ausgabe passend zur App
- konsistente Attribute/Claims
- einheitliche Login-Policy.
Conditional Authentication (CA)
Conditional Authentication im IAS-Kontext ist besonders hilfreich, wenn man Risiko- oder Kontextsignale in Policies übersetzen will, z. B.:
- MFA erzwingen abhängig von Netzwerk/Standort
- strengere Regeln für Admin- oder privilegierte Anwendungen
- Step-up Authentication für sensible Transaktionen
Wichtig ist ein pragmatisches Design: wenige, klare Policies, die man erklären und auditieren kann. Zu viele Sonderfälle erzeugen Betriebsaufwand.
Local Userstore – wann sinnvoll?
Der Local Userstore im IAS ist wertvoll für:
- Externe/Partner ohne Corporate Account
- Break-Glass-Accounts (Notfallzugänge)
- Test-/Service-User (mit sauberer Governance!)
- Interne Developer Accounts oder Sanbox Zugänge oder bei Nutzung von Self-Registration Szenarien im IAS
Best Practice: Local Userstore nicht zum „Schatten-Directory“ werden lassen. Wenn möglich, Externe über geregelte Prozesse (z. B. Partner-IdP oder separates Identity-Verfahren) anbinden und nur notwendige Nutzer pflegen.
Customizing & Best Practices: Konfigurationsmöglichkeiten und bewährte Empfehlungen aus realen Projekten
Konfiguration – worauf es ankommt
- Klare System-of–Record-Definition
- Wer ist Master für welches Attribut? Dokumentieren und durchsetzen.
- Eindeutiger Identifier
- Entscheiden, ob primärer Schlüssel employeeId, personIdExternal, UPN oder E-Mail ist
- E-Mail klingt bequem, ist aber organisatorisch nicht immer stabil (Namensänderung).
- Gruppen-/Rollenstrategie
- Gruppen aus Directory 1:1 übernehmen (einfach) vs. Zielgruppen harmonisieren (sauberer).
- Für BTP: früh klären, wie Gruppen in App-Rollen/Rollencollections abgebildet werden sollen. Klärung wann Group-Mapping und wann Rollenzuweisung zu den Gruppen nötig ist – beides hat seine Berechtigung.
- Transport- und Lifecycle-Setup
- Ein klarer Cutover-Prozess.
- Regeln, Trust-Konfigurationen und Policies versionieren/dokumentieren.
- Betriebskonzept
- Verantwortlichkeiten: Wer behebt Provisioning-Fehler? Wer pflegt Trusts? Wer ändert Policies?
- KPIs: Fehlerrate, Laufzeiten, Anzahl ungeplanter Full Runs, MFA-Ausnahmen.
Quick-Wins aus Projekterfahrung
- Start klein: Erst ein Kern-Use-Case (z. B. IAS + SSO für 1–2 Apps, z.B Fiori Apps in der Workszone), dann skalieren.
- Attribute minimal halten: Nur das provisionieren, was wirklich gebraucht wird – reduziert Fehler und Datenschutzrisiken.
- Naming-Konventionen: für Gruppen, Apps, Trusts und Policies – das zahlt sich spätestens beim zweiten Rollout aus.
- Dokumentation „as-built“: Nicht nur Konzeptfolien, sondern konkrete Konfiguration (Mapping-Logik, Identifier, Ausnahmen).
Lessons Learned aus Projekten mit SAP Cloud Identity Services
Aus unserer Projekterfahrung mit hybriden SAP-Landschaften haben sich einige wiederkehrende Erkenntnisse herauskristallisiert, die über den reinen Funktionsumfang von IAS und IPS hinausgehen.
Erstens haben wir gelernt, dass klare fachliche und technische Verantwortlichkeiten für Identitätsdaten entscheidend sind. Sobald nicht eindeutig definiert ist, welches System führend für welche Objekte st, entstehen inkonsistente Daten, Provisioning-Fehler und unnötige Sonderregeln. Ein früh abgestimmtes Attribut-Ownership-Modell reduziert den Customizing-Aufwand erheblich.
Zweitens zeigt sich immer wieder, dass ein schlanker Start nachhaltiger ist als ein „Big Bang“. Wir erzielen deutlich stabilere Ergebnisse, wenn zunächst ein Kern-SSO-Szenario und ein überschaubarer Provisioning-Flow umgesetzt werden. Auf dieser Basis lassen sich weitere Anwendungen, Attribute und Regeln kontrolliert ergänzen.
Drittens unterschätzen viele Projekte den Betriebsaspekt. Wir haben gute Erfahrungen damit gemacht, Monitoring, Fehlerklassifizierung und klare Support-Prozesse von Anfang an zu definieren. Das senkt die Abhängigkeit von Spezialwissen und macht den Betrieb auch für Linienorganisationen beherrschbar.
Schließlich hat sich bewährt, Transformation Rules bewusst einfach zu halten. Komplexe Logik lässt sich fachlich schwer erklären und technisch schwer debuggen. Klare, modular aufgebaute Regeln erhöhen Transparenz, Wartbarkeit und Akzeptanz bei allen Beteiligten – von IAM über Security bis zum Fachbereich.
Fazit
In hybriden SAP-Landschaften sind IAS und IPS weniger „nur ein weiteres Identity-Tool“, sondern ein pragmatischer Hebel für eine einheitlichen und globalen User Id, SSO, automatisiertes Provisioning und robusten Betrieb. Der Schlüssel zum Erfolg liegt in klaren Verantwortlichkeiten (Master-Daten), sauberem Identifier- und Gruppenmodell, beherrschbarer Transformationslogik und einem Betriebskonzept, das Monitoring und Debugging von Anfang an mitdenkt.
Sie möchten mehr erfahren?
Wir beraten Sie gerne. Nehmen Sie jetzt Kontakt zu uns auf.
Das könnte Sie ebenfalls interessieren
