Identity Concept für SAP-Landschaften: Der Leitfaden für ein tragfähiges IAM

Kaum eine SAP-Initiative scheitert an der Technik allein. Ob S/4HANA-Transformation, BTP-Ausbau oder Analytics-Projekt: Wenn Identitäten, Berechtigungen und Authentifizierung nicht sauber geregelt sind, erbt jedes neue Vorhaben die Altlasten – doppelte Benutzerkonten, inkonsistente Rollen, fragmentierte Login-Erlebnisse. Ein dokumentiertes Identity Concept ist deshalb keine Fleißaufgabe für das Sicherheitsteam, sondern die Grundlage dafür, dass Ihre SAP-Landschaft skalieren kann. Dieser Leitfaden zeigt, worauf es dabei ankommt.

Warum ein Identity Concept? Die Kosten des Chaos

In gewachsenen SAP-Landschaften ist Identität selten geplant worden – sie ist passiert. Jedes System brachte seinen eigenen Benutzerstamm mit, jede Cloud-Anwendung ihren eigenen Login, jede Fachabteilung ihre eigenen Konventionen. Das Ergebnis: Onboarding-Prozesse dauern Tage statt Minuten, Offboarding wird vergessen, Audits werden zur Fleißarbeit, und niemand kann verlässlich beantworten, wer eigentlich worauf Zugriff hat.

Diese Fragmentierung ist nicht nur unbequem, sie ist teuer und riskant. Verwaiste Konten sind ein klassisches Einfallstor, inkonsistente Berechtigungen ein Dauerthema in jeder Wirtschaftsprüfung. Und jedes neue Projekt – von SAP Analytics Cloud bis zur BTP-Erweiterung – zahlt den Preis erneut, weil es auf einer instabilen Identitätsbasis aufsetzt. Ein Identity Concept dreht diese Logik um: Identität wird einmal sauber entworfen, alle Anwendungen bauen darauf auf.

Die drei IAM-Domänen nach SAP

SAP strukturiert Identity & Access Management in drei Kerndomänen, die ein tragfähiges Konzept vollständig abdecken muss:

Identitätslebenszyklus: Wie entstehen Identitäten, wie verändern sie sich, wie werden sie deaktiviert? Vom Eintritt über den Abteilungswechsel bis zum Austritt – idealerweise automatisiert aus einem führenden System wie SuccessFactors oder einem zentralen IdM.
Autorisierung: Wer darf was? Rollen und Berechtigungen müssen nachvollziehbar zugewiesen, regelmäßig überprüft und auditierbar dokumentiert werden.
Authentifizierung: Wie weisen Benutzer ihre Identität nach? Single Sign-On, Multi-Faktor-Authentifizierung und Conditional Access gehören hierher.

Die technische Orchestrierungsgrundlage dafür liefern die SAP Cloud Identity Services (SCI) – bestehend aus dem Identity Authentication Service (IAS), dem Identity Provisioning Service (IPS) und dem Identity Directory. Wichtig zu verstehen: SAP stellt die Werkzeuge, aber die Architekturverantwortung liegt bei Ihnen. Welche Systeme führen, wie föderiert wird, welche Konventionen gelten – das entscheidet kein Produkt, das entscheidet Ihr Konzept.

Sieben Schlüsselprinzipien für ein tragfähiges IAM

1. Identität als First-Class Design Object

Behandeln Sie Identität nicht als nachgelagertes Betriebsthema, sondern als Entwurfsgegenstand mit eigenem Architekturanspruch. Jede Analytik-, Entwicklungs- und Integrationsinitiative erbt die Qualität Ihrer Identitätsbasis – im Guten wie im Schlechten.

2. Hybrid heißt Koexistenz, nicht Eliminierung

ADFS, SAP Single Sign-On 3.0 und On-Premise-Systeme verschwinden nicht über Nacht. Ein realistisches Konzept definiert Brückenszenarien: Kerberos-SNC, Föderation, Rollenabgleich und konsistente Claims über alte und neue Welt hinweg.

3. Proxy-First-Architektur

Setzen Sie den IAS als zentralen Authentifizierungs-Proxy vor Ihren Corporate IdP – etwa Microsoft Entra ID, Okta oder Ping. Die eigentliche Authentifizierung wird delegiert, aber Governance, MFA-Durchsetzung und Token-Claims bleiben zentral steuerbar statt über Dutzende Einzelanbindungen verstreut.

4. Eine Enterprise App pro SAP-Anwendung

Legen Sie im Corporate IdP für jede SAP-Anwendung – jeden BTP-Subaccount, jede SAC-Instanz – eine eigene Enterprise App an. Das ermöglicht anwendungsspezifische Conditional-Access-Richtlinien, kontrollierte Token-Größen, dedizierte Audit-Trails und die saubere Trennung interner, externer und privilegierter Zugriffe.

5. Governance vor Technologie

Bevor Sie konfigurieren, dokumentieren Sie: Welche Anwendung nutzt welchen IdP, welche Attribute, welche Benutzertypen – und wer ist verantwortlich? Eine zentrale Application Matrix mit klarer Ownership und Änderungsprotokoll ist wertvoller als jedes einzelne Feature.

6. Automatisierung und kontinuierliche Verbesserung

Manuelle Benutzerpflege skaliert nicht und ist fehleranfällig. Automatisieren Sie On- und Offboarding entlang des Lebenszyklus und integrieren Sie Ihr IAM mit den Security-Werkzeugen Ihres Unternehmens – ein Identity Concept ist nie fertig, sondern wird betrieben und weiterentwickelt.

7. BYOID – Bring Your Own Identity

SAP baut seine eigenen Touchpoints derzeit konsequent vom proprietären SAP-Login auf föderierte Unternehmensidentitäten um. Wer heute ein sauberes Föderationsmodell mit dem IAS als Brücke etabliert, behält die Kontrolle über MFA, Passwort-Richtlinien und Lifecycle – auch gegenüber SAP selbst.

Praktische Bausteine des Identity Concepts

Tenant-Planung

Planen Sie für die SAP Cloud Identity Services mindestens einen Produktions- und einen Test-Tenant – und widerstehen Sie der Versuchung teamspezifischer Tenants. Richten Sie die Tenant-Strategie an Ihren IAM-Anforderungen aus, nicht mechanisch an der dreistufigen Anwendungslandschaft: Neben der klassischen Aufteilung ist ein konsolidiertes Modell möglich, in dem der Test-Tenant als reine IAM-Validierungsumgebung dient. Wichtig ist auch eine frühe Domänenplanung, um Stolpersteine wie Third-Party-Cookie-Restriktionen zu vermeiden.

Global User ID

Definieren Sie einen stabilen, systemübergreifenden Identifikator für jede Person – die Global User ID. Sie kann in SCI generiert oder beispielsweise aus der Entra Object ID abgeleitet werden und sorgt dafür, dass ein Benutzer über BTP, SAC und SuccessFactors hinweg dieselbe Identität bleibt.

OIDC vor SAML

Wo beide Protokolle zur Wahl stehen, empfiehlt sich OpenID Connect gegenüber SAML – insbesondere für Server-zu-Server-Szenarien. Bei mehreren IdPs hilft Conditional Authentication, den richtigen Anmeldeweg automatisch zu wählen und störende Zwischen-Login-Bildschirme zu vermeiden.

MFA: FIDO2 und TOTP statt SMS

Setzen Sie bei der Multi-Faktor-Authentifizierung auf phishing-resistente Verfahren wie FIDO2/WebAuthn oder zumindest TOTP – und vermeiden Sie SMS-basierte Verfahren. Für technische Verbindungen gilt analog: X.509-Zertifikate mit automatischer Rotation statt Basic Authentication.

Externe Identitäten

Berater, Partner und SAP-Support brauchen ein eigenes Kapitel im Konzept: klare Typisierung der Identitätsarten, eindeutige Ownership und restriktive, zeitlich begrenzte Gast-Richtlinien. Typische Konfliktzonen wie doppelte E-Mail-Adressen oder fehlschlagende MFA-Flows lassen sich so von vornherein vermeiden.

Praxisszenario: Multi-Tenant-Landschaft bei Stadtwerken

Wie tragfähig ein Identity Concept sein muss, zeigt ein Szenario aus dem kommunalen Umfeld: Ein zentraler Tenant der SAP Cloud Identity Services bedient über 50 produktive Tenants mit mehr als 7.500 Benutzern. Die zentrale Benutzerverwaltung fungiert als führendes System, der IPS provisioniert in das Identity Directory und von dort per SCIM in BTP, SAC und Work Zone.

Die entscheidende Einschränkung: Das IAS Directory kennt keine Tenant-Isolation. Alle Benutzer und Gruppen der 50+ Mandanten liegen in einem gemeinsamen Verzeichnis. Was in der Produktbroschüre nicht steht, wird im Konzept zur Überlebensfrage – nur strikte Namenskonventionen wie G_SW-MUNICH_SAC_FI_PROD halten eine solche Landschaft beherrschbar. Wer die Konventionen erst nach dem Rollout definiert, räumt jahrelang auf. Ein weiteres Praxis-Learning aus diesem Szenario: Auch föderierte Benutzer müssen im Identity Directory existieren, damit die SCIM-Provisionierung in die Zielanwendungen funktioniert.

Governance-Werkzeuge: Das Konzept am Leben halten

Ein Identity Concept ist nur so gut wie seine Pflege. Drei Werkzeuge haben sich bewährt:

Application Matrix: Eine zentrale Übersicht aller Anwendungen mit IdP-Zuordnung, Subaccount, Stage, Zielgruppe, Authentifizierungsverfahren, Federation-Modus, MFA-Anforderung, Attributen und – ganz wichtig – benanntem Owner.
Dokumentationsvorlage: Eine strukturierte Vorlage für das hybride Identity Management, die Komponenten, Federation-Modell, Identitätstypen und Sicherheitskonzepte festhält und per Änderungsprotokoll fortgeschrieben wird.
Workshop-Leitfragen: Ein Fragenkatalog von Status quo und Zielbild über Architekturentscheidungen bis zu Governance und Nachhaltigkeit – damit das Konzept nicht am Schreibtisch entsteht, sondern gemeinsam mit den Verantwortlichen.

Fazit

Ein Identity Concept ist kein Dokument für die Schublade, sondern die Architekturentscheidung, auf der jede weitere SAP-Initiative aufsetzt. Wer die drei IAM-Domänen abdeckt, die sieben Schlüsselprinzipien konsequent anwendet und Governance von Anfang an mitdenkt, gewinnt dreifach: weniger Sicherheitsrisiken, weniger Betriebsaufwand und deutlich schnellere Projekte – weil die Identitätsfrage bereits beantwortet ist, bevor sie gestellt wird.

Sie möchten Ihr Identity Concept auf ein solides Fundament stellen? In unserem workshop-basierten Vorgehen erarbeiten wir gemeinsam mit Ihnen Status quo, Zielbild und Architekturentscheidungen – und Sie erhalten ein dokumentiertes Identitätskonzept inklusive erprobter Vorlagen wie der Application Matrix. Erfahren Sie mehr auf unserer Seite Identity & Access Management oder sprechen Sie uns direkt auf einen Workshop an.