Fünf Zugänge vorbereiten.
Danach übernimmt das Installationsportal.

Checkliste für die Kundenadministration vor dem Installationstermin. Mit Klickpfaden, klaren Übergabewerten und einem Abschlusscheck je Zugang. Ohne Zugriff auf ein Quellcode-Repository.

Nur bei Neuinstallationen: Die Schritte mit leerem Ziel-Space gelten ausschließlich für eine Erstinstallation. Bei Updates die bestehende Installation mit ihren IDs, Services und Daten als Ausgangspunkt übernehmen – nichts leeren, löschen oder zur Vorbereitung neu anlegen. Den Updateweg im Deployment Guide verwenden.

Vor dem ersten „Go“

Was Sie hier vorbereiten – und was nicht

IAS ist der Identity Authentication Service für die Anmeldung. SAP Cloud ALM ist das fachliche Zielsystem. Diese Anleitung bereitet ausschließlich Ihre Identitäten, API-Zugänge und Freigaben vor. Eine Person kann mehrere Administratorrollen übernehmen.

Der separate API-Zugang zu SAP Cloud ALM in Abschnitt 4 gehört zu Ihrer vorhandenen SAP Cloud ALM-Landschaft und ist eine Voraussetzung. Er wird nicht als CF-Service im leeren pony-Ziel-Space vorab angelegt.

Vorab gemeinsam festlegen

• Freigegebene CF-API, Organisation, leerer Space und technische Runtime-Subaccount-ID. Im BTP Cockpit den Subaccount über Overview anhand seiner ID prüfen; nicht nur am Anzeigenamen erkennen.
• Kundenhost und davon verschiedener Operation-Host mit der passenden CF-Domain. Nur Namen planen; noch keine Routen erzeugen.
• Mandanten-ID, Anzeigename, Kundengruppe und eigener Destination-Präfix; verantwortliche Administratoren und eine sichere Ablage.
• Tatsächlicher Subaccount für SAP Cloud ALM und Tenant für SAP Cloud ALM. Dieser Subaccount kann vom pony-Runtime-Subaccount abweichen.
• IAS-Tenant, freigegebener Identity Provider, Sicherheitsvorgaben und MFA. Den passenden BTP-Trust durch die Administration prüfen; unbekannte Trusts nicht ersetzen.

Platzhalter wie <customer-host> durch freigegebene eigene Werte ersetzen. Englische SAP-Menünamen sind angegeben; Übersetzungen und Anordnung können abweichen. Dieses Dokument lädt keine Skripte, Bilder oder Schriftarten nach. Lesen und Drucken funktionieren offline; SAP-Links benötigen Internet. Drucken: Strg+P bzw. ⌘P.

SAP-Hintergrund: Authentifizierung und Trust · Cloud-Foundry-Rollen

Zugang 1 von 5

Kundenlogin: eigene IAS-App

Verantwortlich: IAS-/Security-Administration, für die Zuordnung zu SAP Cloud ALM gemeinsam mit der Administration von SAP Cloud ALM.

Diese App meldet Kundenbenutzer an und ermöglicht deren Weiterleitung in das richtige SAP Cloud ALM. Sie ist nicht die Operation-App und nicht der Directory-Systemclient.

IAS-Administration → Applications & Resources → Applications → Create

1. Eine neue eigene OpenID-Connect-App erstellen, beispielsweise pony-example-login. Anwendungstyp, Organisation und Vertragszuordnung mit dem Kunden abstimmen; „Bundled“ ist keine allgemeine Lizenzzusage. Keine SAP-generierte Trust-App ersetzen.
2. In der App die Home URL setzen: https://<customer-host>.<cf-domain>/.
3. Trust → OpenID Connect Configuration öffnen. Einen Konfigurationsnamen und exakt diese Redirect URI speichern: https://<customer-host>.<cf-domain>/ias-callback. Keine Wildcard und keine fremde Route eintragen. Der Login verwendet Authorization Code mit einem geheimnisgeschützten Client, keinen Public Client.
4. Unter Trust → Subject Name Identifier den Wert Email wählen. Standardattribute beibehalten; keine zusätzliche E-Mail- oder Gruppen-Rollenbrücke improvisieren.
5. Trust → Client Authentication → Secrets → Add öffnen. Beschreibung und vereinbartes Ablaufdatum setzen. Beim API-Zugriff nur OpenID auswählen; vorgewählte Verwaltungszugriffe abwählen. Neue Client-ID und einmal sichtbares Secret direkt geschützt sichern.
6. Unter OpenID Connect Configuration → Authentication → Grant Types → Edit zusätzlich Token Exchange (RFC 8693) aktivieren. Anschließend unter Trust → Application APIs → Dependencies eine Dependency mit dem festen Namen PONY_CALM für den XSUAA-Provider der tatsächlichen Instanz von SAP Cloud ALM des Kunden mit Principal Propagation einrichten. Den genauen Provider durch die Administration von SAP Cloud ALM bestätigen lassen; nicht nach ähnlich klingenden Anwendungsnamen entscheiden.
7. Kundengruppe, Benutzerzugriff und MFA gemäß Kundenfreigabe einstellen. Für Kundenadministratoren muss Pony_Admin aus SAP Cloud ALM stammen; eine gleichnamige IAS-Gruppe ersetzt diese Rolle nicht.

Erledigt, wenn: Die erneut geöffnete App die richtige Kundenroute, Subject Email, OpenID-Zugang und die Dependency PONY_CALM zeigt und beide Credential-Werte gesichert sind. Der tatsächliche Kundenlogin mit Token Exchange wird erst nach der Installation abgenommen.

Sicherer Ablageort (keine Zugangsdaten):   · Verantwortlich:   · Secret-Ablauf:  

SAP: OIDC-App erstellen · Client-Secrets und OpenID-Zugriff · Token Exchange konfigurieren · API-Dependencies

Zugang 2 von 5

Operation-Login: separate IAS-App

Verantwortlich: IAS-/Security-Administration und BTP-Administration.

Dieser Zugang ist für das pony-Operation-Cockpit. Er benötigt keinen Login in SAP Cloud ALM des Kunden. Er ist auch nicht der technische BTP-API-Zugang aus Abschnitt 5.

IAS-Administration → Applications & Resources → Applications → Create

1. Eine zweite eigene OpenID-Connect-App erstellen, beispielsweise pony-example-operation. Keine Client-ID und kein Secret aus der Kunden-App übernehmen. Derselbe IAS-Tenant ist möglich; die Apps bleiben getrennt.
2. Als Home URL https://<operation-host>.<cf-domain>/custom/operator.html setzen.
3. Unter Trust → OpenID Connect Configuration Konfigurationsname und https://<operation-host>.<cf-domain>/ias-callback als exakte Redirect URI speichern. Authorization Code verwenden; keinen Public Client einrichten.
4. Unter Trust → Subject Name Identifier ebenfalls Email wählen. Unter Client Authentication → Secrets → Add ein eigenes Secret mit vereinbartem Ablauf erzeugen, ausschließlich OpenID auswählen und Client-ID plus Secret direkt geschützt sichern.
5. Keine Dependency zur Instanz von SAP Cloud ALM des Kunden in dieser App einrichten. Die vorgesehenen Operation-Benutzer müssen im pony-Runtime-Subaccount der Role Collection Pony_Operator mit dem richtigen Identity Provider zugeordnet sein. BTP-Pfad: Security → Role Collections → Pony_Operator → Edit → Users. Eine fehlende Collection durch die zuständige Administration vorbereiten lassen.

Erledigt, wenn: Operation-Route, OIDC-Client und gesicherte Zugangsdaten eindeutig von der Kunden-App getrennt sind, Subject Email gespeichert ist und die vorgesehene Operation-Zuordnung im richtigen Subaccount bestätigt wurde. Operation-Login und Rollen-Refresh werden nach dem „Go“ separat getestet.

Sicherer Ablageort (keine Zugangsdaten):   · Verantwortlich:   · Secret-Ablauf:  

SAP: Eigene OIDC-Anwendung · Authorization Code Flow · Client-Secrets

Zugang 3 von 5

Benutzersuche: Directory mit Read Users

Verantwortlich: IAS-/Security-Administration.

pony benötigt hierfür einen separaten technischen IAS-Systemclient. Weder das Passwort eines Menschen noch einer der beiden Loginclients gehört in diesen Zugang.

IAS-Administration → Users & Authorizations → Administrators → Add → System

1. Einen eigenen Systemnamen vergeben, beispielsweise pony-example-directory.
2. Unter Configure Authorizations vor dem Speichern alle vorgewählten Manage-Berechtigungen ausschalten. Ausschließlich Read Users aktivieren. Keine Benutzer-, Gruppen-, Anwendungs- oder Tenantverwaltung und keine Provisionierungsrechte freigeben.
3. Unter Configure System Authentication → Secrets → Add ein eigenes Secret mit Beschreibung und Ablauf erzeugen. Die Client-ID dieses Systemclients und das einmal sichtbare Secret direkt in einer eigenen geschützten Ablage sichern.
4. Den gespeicherten Systemclient erneut öffnen und die Berechtigungen nachlesen. Die Administration bestätigt den freigegebenen lesenden Directory-Zugriff; dabei keine Benutzerlisten exportieren oder im Protokoll ausgeben.

Erledigt, wenn: Genau der neue Systemclient ausschließlich Read Users besitzt, seine Zuordnung zum Kunden-IAS bestätigt ist und Client-ID sowie Secret sicher vorliegen. Ein Loginclient oder ein Systemclient mit Manage-Rechten erfüllt diese Voraussetzung nicht.

Sicherer Ablageort (keine Zugangsdaten):   · Verantwortlich:   · Secret-Ablauf:  

SAP: Benutzerberechtigungen und Reichweite von Read Users · Sicherer Umgang mit neu erzeugten Secrets

Zugang 4 von 5

Fachliche API: eigener SAP Cloud ALM-Zugang

Verantwortlich: Administration von SAP Cloud ALM; Service- und Kostenfreigabe durch den zuständigen Kundenverantwortlichen.

Hier zählt der Subaccount mit der tatsächlichen Subscription für SAP Cloud ALM, nicht automatisch der pony-Runtime-Subaccount. Den Ziel-Tenant und seine technische ID vor dem ersten Klick bestätigen.

BTP Cockpit → Subaccount für SAP Cloud ALM → Services → Instances and Subscriptions → freigegebene API-Instanz von SAP Cloud ALM

1. Die benötigten pony-Funktionen und die dafür erlaubten API-Scopes abstimmen. Der pony-Lieferverantwortliche stellt eine passende, freizugebende Parameterbasis bereit; dafür ist beim Kunden kein Repositoryzugang nötig.
2. Geeignete Instanz vorhanden? Diese konkrete Instanz für pony ausdrücklich freigeben lassen und gezielt auswählen. Vorhandene Bindings und Scopes unverändert lassen. Keine Credentials anderer Umgebungen übernehmen. Das neue eigene Binding entsteht einmalig in Schritt 4.
3. Keine geeignete Instanz vorhanden? Erst Service, Scopes und Kosten freigeben lassen. Danach im Subaccount für SAP Cloud ALM über Create den Service SAP Cloud ALM API, Plan standard, Runtime Other / Andere und einen eigenen Namen wählen. Die freigegebene kundeneigene Parameterdatei im Wizard hochladen. Weder bestehende Instanzen ungefragt aktualisieren noch einen CF-Service für SAP Cloud ALM im pony-Ziel-Space anlegen.
4. Auf die verwendbare Instanz warten. Dort Actions → Create Binding / Service-Binding anlegen wählen und einen eindeutigen eigenen Bindingnamen vergeben, beispielsweise pony-example-sap-cloud-alm-api. Anschließend am neuen Binding Actions → View / Anmeldeinformationen anzeigen öffnen.
5. Nur dieses neue Binding geschützt sichern. Die Administration von SAP Cloud ALM bestätigt zusätzlich die SAP Cloud ALM-Anwendungs-URL, API-Basis-URL, den Authentifizierungs-Host und den expliziten Token-Endpunkt. Eine generische uaa.url nicht ungeprüft als Kunden-Authentifizierungs-Host von SAP Cloud ALM verwenden.

Erledigt, wenn: Eigenes Binding und eindeutige Zuordnung zu SAP Cloud ALM vorliegen, die Rechte ausdrücklich freigegeben sind und die Administration den technischen Tokenzugriff sicher geprüft hat. Keine Tokens oder Antwortinhalte protokollieren. Ein gültiges technisches Token beweist noch nicht den späteren Kundenlogin mit Benutzer-Token-Exchange.

Sicherer Ablageort (keine Zugangsdaten):   · Verantwortlich:   · Scope-Freigabe:  

SAP: API von SAP Cloud ALM und Binding im Cockpit vorbereiten · SAP Cloud ALM-Scopes verwalten · Felder der Binding-Credentials

Zugang 5 von 5

Rollenprüfung: Read-only-BTP-API

Verantwortlich: BTP-Administration des pony-Runtime-Subaccounts.

Dieser technische Zugang liest die BTP-Operation-Zuordnung. Er ist weder das Operation-IAS-Secret noch ein API-Key für SAP Cloud ALM oder Application-XSUAA-Service-Key. Benötigt wird ein eigener API-Zugang mit read-only für genau den Runtime-Subaccount.

Zuerst im Cockpit: Ziel und Operation-Benutzer prüfen

BTP Cockpit → pony-Runtime-Subaccount → Overview; anschließend Security → Role Collections → Pony_Operator

1. Die technische Subaccount-ID mit CF-Org und Ziel-Space abgleichen. Im leeren Space gibt es noch kein neues pony-XSUAA-Binding; keines vorab erstellen. Der Installationsauftrag prüft die ID später zusätzlich am von ihm angelegten Binding.
2. Unter Pony_Operator die freigegebenen Operation-Benutzer mit dem richtigen Identity Provider prüfen. Ein gleicher E-Mail-Text bei einem anderen Provider ist keine ausreichende Zuordnung. Den vorgesehenen aktiven IAS-Trust bestätigen lassen.

Nur für diesen Zugang: BTP CLI durch die Administration

Für die separate API-Credential-Erzeugung verwendet der dokumentierte SAP-Weg die BTP CLI. Sie ist nicht die CF CLI: btp verwaltet hier den Subaccount-Zugang; cf verwendet später der Installationsauftrag für Apps und Services. Beide Werkzeuge haben getrennte Anmeldung und Zielauswahl. Die BTP CLI ist ein Vorbereitungswerkzeug der Administration, keine zusätzliche Laufzeitabhängigkeit des Installationsportals.

1. Die BTP CLI über den offiziellen SAP-Link beschaffen. In einem geschützten Administrationsfenster am richtigen Global Account anmelden. Passwort interaktiv eingeben bzw. den freigegebenen SSO-Weg verwenden: kein Passwort, Secret oder JWT als Kommandozeilenargument, keine Tracing-/Verbose-Ausgabe, keine Terminalaufzeichnung.
2. Vor der Anlage btp get accounts/subaccount "<subaccount-id>" ausführen und die technische Zielzuordnung prüfen. Die Subdomain des Global Accounts ist weder der IAS-Host noch der CF-Space.
3. Ein neues eigenes API-Credential mit --read-only true und expliziter Subaccount-ID erzeugen. Die Ausgabe enthält das Secret: sie direkt in eine neue geschützte UTF-8-Datei außerhalb des Pakets und eines Repositories schreiben. Zielordner vorher nur für den ausführenden Benutzer freigeben; unter Linux/WSL zusätzlich umask 077. Vorhandene Credential-Dateien nicht überschreiben.

Beispiel für Linux/WSL (Bash) oder Windows-Eingabeaufforderung (cmd.exe), nach sicherer Anmeldung. Beide Platzhalter ersetzen. Die Umleitung verhindert, dass die Credential-Ausgabe auf dem Bildschirm erscheint. Nicht mit abweichender PowerShell-Standardkodierung als Datei erzeugen.

btp --format json create security/api-credential --name pony-example-operation-read --read-only true --subaccount "<subaccount-id>" > "<new-secure-file>"

Die Administration prüft den erfolgreichen Befehl und die zurückgemeldete Read-only-Einstellung ohne Secret-Ausgabe. Die Datei unverzüglich geschützt sichern. Kein cf create-user-provided-service und keine Destination erstellen: Das übernimmt der Installationsauftrag nach „Go“.

Im aktuellen Portal diese sechs Werte ausschließlich in die geschützten Felder dieses Zugangs eintragen. Ein historischer lokaler Assistent kann sie aus einer lokalen JSON-Datei einlesen, direkt auf der obersten Ebene oder unter credentials. Bei anders aufgebautem CLI-Export die Felder einzeln aus der sicheren Ablage übernehmen oder die Administration eine passende geschützte Datei bereitstellen lassen. Keine Online-Konverter verwenden; keine Datei in dieses Handbuch einkleben.

Erledigt, wenn: Neuer eigener Client, Read-only-Einstellung, technische Subaccount-ID und Operation-Zuordnung bestätigt sind und alle sechs Werte sicher vorliegen. Die Administration prüft erforderliche Rollen-/Trust-Leserechte ohne Benutzerlisten oder Tokens zu exportieren. Bei Ablehnung keine Vollzugriffs-Credentials als Ersatz anlegen.

Sicherer Ablageort (keine Zugangsdaten):   · Verantwortlich:   · Read-only geprüft:  

SAP: BTP CLI herunterladen · Separaten API-Zugang beschaffen · API-Credential-Befehl und Optionen

Übergabe an die ausführende Person

Bereit für das Installationsportal?

Die folgenden Angaben gehören ins Kundendatenblatt bzw. in die sichere Ablage, nicht als Klartext-Geheimnisse in dieses Dokument.

• Alle fünf Zugänge sind getrennt, geprüft und über ihre Hinweise auf den sicheren Ablageort erreichbar. Ablaufdaten, Rotation und Ansprechpartner sind festgehalten.
• Der pony-Ziel-Space ist weiterhin leer. Keine DB, CF-Services, Runtime-Dienste, Destinations, Apps oder Routen wurden dafür manuell vorbereitet.
• Eigene CF-Zielwerte, Namen, Kundengruppe, Destination-Präfix sowie DB-/App-Größen und Kosten sind freigegeben. Der CF-Deploybenutzer besitzt die nötigen Rechte für genau diesen Space.
• Aktuelles Installationsportal: Der Kunde benötigt nur einen unterstützten Browser und den freigegebenen Portalzugang. Bei interaktiver MFA-/SSO-Anmeldung den vorgesehenen Portalablauf verwenden – niemals MFA deaktivieren. Nur für ausdrücklich bereitgestellte historische lokale Pakete: In der Windows-x64-Ausgabe sind Node.js 24 und CF CLI 8 im ZIP enthalten; vollständig lokal entpacken, keine Vorinstallation. Unternehmensrichtlinien müssen die Ausführung erlauben. Für eine separate Linux/macOS-Ausgabe beide Tools vorab bereitstellen; die Passwortanmeldung des lokalen Installers muss mit dem freigegebenen CF-Zugang nutzbar sein.
• Ein eigener kryptografisch zufälliger Verschlüsselungsschlüssel mit 64 Hex-Zeichen und ein eigenes zufälliges Runtime-DB-Passwort mit 43–128 Zeichen (A–Z, a–z, 0–9, _ oder -) sind geschützt gesichert. Nicht aus anderen Umgebungen übernehmen; bei Wiederaufnahme dieselben Werte verwenden. Vor der Eingabe im Portal ausdrücklich wählen und prüfen, ob Geheimnisse nur für die laufende Sitzung freigegeben oder in einem verschlüsselten Installationsstand gespeichert werden; ohne eine solche Anzeige keine dauerhafte Portalspeicherung annehmen.
• Das freigegebene Lieferpaket stammt aus dem vereinbarten Kanal. Die getrennt übermittelte Prüfsumme ist verglichen; das ZIP wird vollständig entpackt.

Kunde / Ziel:   · Übergabe am:   · Freigegeben durch:  

Diese Datei ist die eigenständige Identitätsvorbereitung für das pony-Installationsportal und ausdrücklich bereitgestellte historische lokale Installationspakete. Sie ist keine Anleitung zur manuellen Bereitstellung der pony-Cloud-Ressourcen. Technischer Dokumentationsstand: September 2026; konkrete Kundenziele, SAP-Vertragsumfang und Freigaben gehen Beispielnamen vor.