Ablösung der SAP ZBV: SAP Cloud Identity Service als moderne Nachfolgelösung

Die ZBV war die richtige Antwort — auf eine Landschaft, die es nicht mehr gibt

Wer heute eine gewachsene SAP-Landschaft betreibt, betreibt mit hoher Wahrscheinlichkeit auch eine Zentrale Benutzerverwaltung. Die ZBV — international als Central User Administration (CUA) bekannt — wurde eingeführt, als ein klares Bild vom Rechenzentrum galt: eine Handvoll ABAP-Systeme, alle im eigenen Netz, alle mit lokalem Kennwort, alle über ALE und tRFC erreichbar. Für diese Welt war die ZBV eine elegante Lösung. Ein Zentralsystem, ein SU01, eine Verteilung.

Diese Welt hat sich verschoben. In derselben Landschaft laufen heute S/4HANA in RISE, mehrere BTP-Subaccounts, SaaS-Anwendungen und ein Konzern-Verzeichnis, das in Microsoft Entra ID liegt und nicht mehr im ABAP-Stack. Die ZBV kann davon nichts sehen. Sie verteilt Benutzer an ABAP-Systeme — und ausschließlich dorthin.

Damit steht früher oder später eine Architekturentscheidung an, die in vielen Projekten zu spät gestellt wird: Was tritt an die Stelle der ZBV? Die Antwort lautet: die SAP Cloud Identity Services. Aber sie treten nicht so an ihre Stelle, wie die meisten es erwarten — und genau dieses Missverständnis soll dieser Artikel auflösen.

Was die ZBV wirklich leistet, und wo ihre Grenze verläuft

Bevor man über Nachfolge spricht, lohnt der nüchterne Blick auf das, was die ZBV tatsächlich tut. Sie ist ein Verteilmechanismus innerhalb des ABAP-Stacks, technisch aufgesetzt auf ALE und tRFC:

•     Das Zentralsystem hält den führenden Benutzerstamm. Angelegt wird in SU01, verteilt wird per IDoc.

•     SCUM legt feldgenau fest, welches Attribut global, lokal, als Vorschlag oder überall gepflegt wird.

•     Rollen- und Profilzuordnungen werden mitverteilt, Bestandsbenutzer über SCUG eingesammelt.

•     SCUL ist das Protokoll, in dem man nachsieht, warum eine Verteilung nicht angekommen ist.

Das ist innerhalb seines Rahmens funktional und über Jahre erprobt. Die Grenze ist keine Frage der Qualität, sondern des Zuschnitts.

Sie endet am ABAP-Stack. Ein BTP-Subaccount, ein SaaS-Dienst, eine Fiori-Anwendung außerhalb des Verbunds — nichts davon ist ein ZBV-Ziel. In der Praxis führt das zu genau dem Zustand, den niemand geplant hat: ZBV für die Kernsysteme, manuelle Pflege in der BTP, Excel-Listen für den Rest.

Sie kennt keine Identität, nur Benutzer. Die ZBV verteilt Benutzerstämme. Sie hat kein Konzept davon, dass derselbe Mensch in Entra ID, im HR-System und in fünf SAP-Mandanten existiert und dass sein Austritt überall gleichzeitig wirken muss.

Sie ist kennwortbasiert. MFA, Conditional Access, passwortlose Verfahren, gerätebasierte Compliance-Prüfungen — all das findet in der Welt des Konzern-Identity-Providers statt, nicht in der ZBV.

Sie hat keine Governance-Schicht. Wer hat wann welche Berechtigung erhalten, und wer hat das bestätigt? Aus SCUL lässt sich diese Frage nicht beantworten.

Hinzu kommt der strategische Punkt — und der ist differenzierter, als es das Wort „Legacy“ vermuten lässt. Die ZBV verschwindet nicht. Sie bleibt verfügbar und funktionsfähig, auch unter SAP S/4HANA in der Private Cloud Edition. Es gibt also keinen Stichtag, der zum Handeln zwingt. Was es aber gibt: Die ZBV wird nicht weiterentwickelt. Sie bleibt ein Legacy-Produkt, das den heutigen Zuschnitt einer SAP-Landschaft nicht abdeckt — und ihn auch künftig nicht abdecken wird.

Der Grund für eine Ablösung ist deshalb kein Wartungsende, sondern eine Architekturentscheidung: Wer Cloud und On-Premise unter einem einheitlichen IAM-Bild betreiben will, kommt mit einem ABAP-internen Verteilmechanismus nicht dorthin. Wer die ZBV weiterbetreibt, tut das legitim — aber er betreibt sie neben allem anderen, nicht als Teil eines Gesamtkonzepts.

Die Nachfolge ist kein Produkt, sondern eine Architektur

Hier liegt das Missverständnis, das in Projektgesprächen am meisten Zeit kostet: Die Cloud Identity Services sind nicht „die ZBV in der Cloud“. Wer versucht, das ZBV-Modell eins zu eins nachzubauen, migriert das falsche Zielbild — und wundert sich anschließend, dass die neue Lösung sich an mehreren Stellen sperrt.

Der Unterschied ist grundlegend und betrifft die Frage, wo die führende Quelle liegt.

In der ZBV war das Zentralsystem selbst die Quelle der Wahrheit. Ein Benutzer entstand dort, weil ihn dort jemand angelegt hat. In der SAP-Referenzarchitektur wandert diese Rolle aus SAP heraus: Führend ist das Konzern-Verzeichnis — Active Directory, Entra ID oder ein HR-System. Die SAP Cloud Identity Services sind nicht die Quelle, sondern die vermittelnde Identitätsschicht dazwischen. Die Zielsysteme wiederum werden zu reinen Konsumenten: Sie halten keinen führenden Benutzerstamm mehr, sondern eine provisionierte Kopie.

Konkret bestehen die Cloud Identity Services aus drei Komponenten mit klarer Arbeitsteilung:

•     Identity Authentication Service (IAS) — die zentrale Authentifizierungsinstanz. Im Zielbild typischerweise im Betriebsmodus Proxy with Federation: Der IAS vermittelt die Anmeldung an den Corporate Identity Provider und verwaltet selbst keine Kennwörter.

•     Identity Provisioning Service (IPS) — die Synchronisation. Er liest Identitäten aus den Quellen und schreibt Benutzer sowie berechtigungsrelevante Gruppenzugehörigkeiten in die Zielsysteme.

•     Identity Directory — die persistente Identitätsablage in der Cloud. Sie hält die SAP-interne Sicht auf den Benutzer und ist der Ort, an dem Zugriffe zugewiesen werden.

Damit wird das Identity Directory zu dem, was das ZBV-Zentralsystem einmal war: dem einen Ort, an dem man sieht, wer Zugriff auf welches System hat. Nur reicht dieser Ort jetzt über ABAP und Cloud hinweg.

Mit oder ohne bestehende IDM-Lösung — beide Wege tragen

Eine Frage steht in diesen Projekten früh im Raum: Was passiert mit einer bereits vorhandenen IDM-Infrastruktur? Muss die weichen? Nein — und das ist einer der praktischen Vorzüge dieses Zielbilds.

Ist eine IDM-Lösung im Einsatz, lassen sich die Cloud Identity Services nahtlos daran anbinden. Das IDM bleibt führend für das, worin es stark ist: Genehmigungsworkflows, Rezertifizierung, unternehmensweite Rollenlogik über SAP hinaus. Die Cloud Identity Services übernehmen die SAP-seitige Umsetzung — Verteilung in die Zielsysteme und Authentifizierung. Statt zweier konkurrierender Wahrheiten entsteht ein durchgängiges Konzept, in dem jede Schicht genau eine Aufgabe hat.

Ist keine IDM-Lösung im Einsatz, lassen sich die Cloud Identity Services ebenso gut eigenständig betreiben: Verzeichnis als Quelle, Identity Directory als zentrale Zuweisungsstelle, IPS als Verteilung. Für viele Landschaften ist das vollständig ausreichend — und gegenüber der ZBV bereits ein deutlicher Schritt nach vorn. Ein IDM ist damit keine Voraussetzung, sondern eine Option, die sich später ergänzen lässt, ohne das Zielbild neu zu bauen.

Das Zielbild in drei Ebenen: Authentifizierung, Provisionierung, Autorisierung

Ein tragfähiges Zielbild trennt drei Ebenen konsequent. Wer sie vermischt, baut ein Konzept, das im Betrieb an den Nahtstellen bricht.

Ebene 1 — Authentifizierung: einmal anmelden, überall

Das Konzern-Verzeichnis wird über einen einmaligen Metadaten-Austausch als Corporate Identity Provider am IAS angebunden, üblicherweise per SAML 2.0. Jede SAP-Anwendung — Cloud wie On-Premise — wird im IAS als Applikation registriert. Der Endbenutzer meldet sich mit seinem Verzeichnis-Konto an; in den Zielsystemen existiert kein lokales Kennwort mehr.

Für Cloud-Anwendungen ist das über die Vertrauensbeziehung im BTP-Cockpit direkt umsetzbar. Für die ABAP-Welt — On-Premise wie RISE — braucht es eine zusätzliche Komponente: den SAP Secure Login Service. Der Secure Login Client auf dem Benutzerhost leitet die Authentifizierung über den IAS an den Corporate IdP weiter und erhält ein X.509-Zertifikat, mit dem sich der Benutzer am ABAP-System anmeldet. Kerberos und SPNEGO können dabei weiterhin genutzt werden. Fiori-Systeme lassen sich alternativ direkt per SAML 2.0 anbinden — mit dem Nachteil, dass die Konfiguration dann mandantenspezifisch erfolgt.

Ein Hinweis, der für die Planung wichtiger ist, als er klingt: Der SAP Secure Login Service ist der Nachfolger von SAP SSO 3.0, dessen Wartung SAP zum 31.12.2027 beendet. Wer die ZBV-Ablösung plant, sollte diesen Termin im gleichen Projektzuschnitt mitdenken, statt zwei Migrationen hintereinander zu fahren.

Ebene 2 — Provisionierung: Identität immer vorab schreiben

Das Verzeichnis ist die Quelle der Benutzeridentitäten. Der IPS liest jobbasiert und zyklisch alle Benutzer in das Identity Directory, die einer definierten Gruppe zugeordnet sind. Die technische Anbindung eines On-Premise-Verzeichnisses erfolgt über den Cloud Connector mit einer lesenden LDAPS-Verbindung.

Aus dem Identity Directory heraus wird der angereicherte Benutzerstamm in die Zielsysteme geschrieben — ABAP-Dialogbenutzer und BTP-Applikationsbenutzer. Der Filter, ob ein Benutzer in ein bestimmtes Zielsystem geschrieben wird, ist seine Gruppenzugehörigkeit im Identity Directory.

Entscheidend ist der Grundsatz: kein Shadow-User-Konzept. Ein Benutzer, der erst bei der ersten SSO-Anmeldung im Zielsystem entsteht, hat keine saubere Lifecycle-Anbindung an die Quelle. Verlässt er die Organisation, bleibt sein Datensatz bestehen, bis ihn jemand aktiv findet. Wird die Identität stattdessen vorab durch den IPS provisioniert, greift beim Austritt automatisiertes Deprovisioning. Auf dieser Ebene gibt es deshalb nur eine Antwort: immer provisionieren.

Ebene 3 — Autorisierung: eine Gruppe pro Rolle, mit Präfix

Auf der Berechtigungsebene unterscheidet sich die technische Umsetzung deutlich zwischen ABAP und Cloud — und genau hier wird das Rollenmodell entweder tragfähig oder zur Dauerbaustelle.

Für die ABAP-Systeme werden die berechtigungsrelevanten PFCG-Rollen in das Identity Directory geladen und dabei mit einem System- und Mandanten-Präfix versehen. Eine PFCG-Rolle entspricht dann genau einer CIS-Gruppe. Die Rolle Z_FI_BUCHHALTER aus Mandant 100 des Systems PRD wird zur Gruppe PRD.100_Z_FI_BUCHHALTER. Diese Konvention ist nicht Kosmetik: Sie ist der Mechanismus, über den die Systemzuordnung eindeutig bleibt und über den der Provisionierungsfilter greift.

Für BTP-Anwendungen wird im Subaccount eine Role Collection definiert und im Trust-Config-Mapping mit einer CIS-Gruppe verknüpft. Der Benutzer erhält seine Berechtigung dann über sein Gruppenattribut aus dem Token. Wichtig dabei: Die Subaccounts vertrauen ausschließlich den Cloud Identity Services als Identity Provider, nie direkt dem Konzern-Verzeichnis. Jedes ausgewertete Attribut stammt aus dem bereits provisionierten Identity Directory und nicht aus einem live durchgereichten Claim.

Wer an dieser Stelle tiefer einsteigen möchte, welche Zuweisungsmethode auf der BTP wann die richtige ist, findet die Details in unserem Artikel Provisioning vs. Federated Role Assignment auf SAP BTP.

Was in der Migration tatsächlich Arbeit macht

Der technische Aufbau der Cloud Identity Services ist überschaubar. Die Arbeit liegt an anderer Stelle — und ehrlicherweise auch dort, wo die neue Architektur weniger kann als die alte. Vier Punkte, die man früh adressieren sollte:

Die globale Benutzersperre. Was in SU01 ein Klick war, ist über die Cloud Identity Services nicht eins zu eins abbildbar. Der praktikable Weg ist die Sperre im Identity Provider — damit ist keine SSO-Anmeldung mehr möglich — ergänzt um ein Valid To im Identity Directory und den Entzug der Gruppen. Das ist sauber protokolliert, aber es ist ein anderer Prozess, und er muss als solcher beschrieben und geschult werden.

Zeitliche Abgrenzung von Berechtigungen. Eine befristete Rollenzuordnung, wie sie in der PFCG selbstverständlich ist, lässt sich im Identity Directory nicht ohne Weiteres abbilden. Für Szenarien wie Auszubildende in Durchläufen, Vertretungen oder Firefighter-Zugriffe braucht es entweder ein Governance-Modul, eine nachträgliche Abgrenzung im Zielsystem oder einen organisatorischen Prozess. Diese Entscheidung sollte im Konzept stehen und nicht im Betrieb entstehen.

Attribute ohne native Entsprechung. Lizenzdaten und Abrechnungsnummern im SU01-Benutzerstamm — betriebswirtschaftlich relevant, technisch nicht vorgesehen. Der gangbare Weg führt über Custom Attributes im Identity Directory und ein entsprechendes Mapping. Man sollte allerdings wissen, dass es dabei weder Wertehilfen noch eine systemabhängige Differenzierung gibt.

Der Abbau der ZBV selbst. Der am häufigsten unterschätzte Schritt. Solange ein Zielsystem noch Teil eines ZBV-Verbunds ist, konkurrieren zwei Mechanismen um denselben Benutzerstamm. Der ZBV-Verbund muss deshalb kontrolliert aufgelöst werden, bevor oder während der IPS die Hoheit übernimmt — sonst überschreiben sich Verteilung und Provisionierung gegenseitig, und die Fehlersuche findet in zwei Protokollen gleichzeitig statt.

Fazit

Die Ablösung der ZBV ist kein Werkzeugtausch. Sie ist die Entscheidung, die führende Quelle für Identitäten aus SAP herauszulösen und die SAP-Landschaft — ABAP und Cloud gemeinsam — zum Konsumenten einer zentralen Identitätsschicht zu machen. Wer das versteht, gewinnt mehr als den Ersatz einer Legacy-Komponente: ein Zielbild, in dem Authentifizierung, Provisionierung und Autorisierung über die gesamte Landschaft hinweg dieselbe Sprache sprechen, in dem ein Austritt automatisiert überall wirkt und in dem Audits nicht mehr in Verteilungsprotokollen enden.

Der Zeitpunkt dafür wird nicht von SAP diktiert — die ZBV bleibt verfügbar, auch unter S/4HANA in der Private Cloud Edition. Er wird von der eigenen Landschaft diktiert: von dem Moment an, in dem der erste BTP-Subaccount oder der erste Cloud-Dienst neben der ZBV verwaltet werden muss. Wer die ZBV dann lediglich nachbaut, bekommt eine Cloud-Komponente mit ABAP-Denkweise — und die Grenzen der alten Lösung gleich mit.

Sie betreiben noch eine ZBV und möchten wissen, wie ein tragfähiges Zielbild für Ihre zukünftige Landschaft aussieht? Es gibt dafür keine Standardantwort — ob eine bestehende IDM-Infrastruktur eingebunden wird, welche Systeme in welcher Welle folgen und wie mit Sperr-, Befristungs- und Lizenzthemen umgegangen wird, entscheidet sich an Ihrer Landschaft. Genau dort setzen wir an: Wir beraten Sie individuell und erarbeiten mit Ihnen ein auf Ihre Systeme zugeschnittenes IAM-Konzept samt Migrationsplan — von der Analyse des Bestands über das Zielbild bis zur wellenweisen Umsetzung. Erfahren Sie mehr über unsere Beratung zu Identity & Access Management für SAP-Landschaften.

Für die Plattform-Themen dahinter — Architektur, Subaccounts, Security — steht Ihnen unsere SAP BTP Beratung zur Seite.