Ohne Principal Propagation sehen alle Anwender die Daten eines technischen Benutzers. Wie die Identitätsweitergabe von der BTP bis ins S/4HANA funktioniert, was Sie dafür einrichten und wann ein anderes Verfahren die bessere Wahl ist.
Ihre Anwendung auf der SAP BTP läuft. Die Daten kommen aus S/4HANA. Aber wissen Sie, als wer Ihre Anwender dort tatsächlich ankommen?
In vielen Anbindungen lautet die Antwort: als ein und derselbe technische Benutzer. Das ist kein Konfigurationsfehler, sondern der Normalzustand nach dem ersten erfolgreichen Verbindungstest. Und genau dort bleibt es dann oft stehen.
Die wichtigste Aussage vorweg: Ohne Principal Propagation ist Ihr SAP-Berechtigungskonzept in jeder Cloud-Anwendung praktisch außer Kraft. Die Technik dagegen ist im Standard enthalten und kostet keine zusätzliche Lizenz. Sie muss nur an drei Stellen gleichzeitig eingerichtet werden.
Eine Destination, also das Konfigurationsobjekt auf der BTP, das festlegt wo ein Zielsystem liegt und wie man sich dort anmeldet, enthält im einfachsten Fall einen technischen Benutzer mit Passwort. Das ERP sieht damit bei jeder Anfrage dieselbe Kennung, unabhängig davon, wer in der Cloud davor sitzt.
Drei Folgen, die in Prüfungen regelmäßig auffallen:
Das Berechtigungskonzept greift nicht. Jeder Anwender sieht das, wofür der technische Benutzer berechtigt ist. Das ist fast immer zu viel, und es fällt selten auf, weil die Anwendung ja funktioniert.
Der Nachweis fehlt. Im Security Audit Log steht eine Sammelkennung statt eines Namens. Wer eine Buchung ausgelöst hat, lässt sich nicht mehr feststellen.
Funktionstrennung ist nicht prüfbar. Sie setzt voraus, dass Handlungen einzelnen Personen zuzuordnen sind. Über eine gemeinsame Kennung ist das nicht möglich.
Der Cloud Connector ist die Software, die Sie im eigenen Netz installieren und die eine ausgehende, verschlüsselte Verbindung zur BTP aufbaut. Er reicht aber nicht nur Daten durch. Er nimmt das Anmeldetoken aus der Cloud entgegen, prüft es und stellt daraufhin ein kurzlebiges X.509-Zertifikat aus. Das ist ein digitaler Ausweis, der nur Sekunden gültig ist. Das ABAP-System prüft diesen Ausweis und ordnet ihn einem SU01-Benutzer zu.
Ab diesem Punkt gilt wieder, was ohnehin definiert ist: die vorhandenen SAP-Rollen. Es entsteht kein zweites Berechtigungskonzept in der Cloud, das dauerhaft gepflegt werden müsste.
Hier liegt der Grund, warum die Einrichtung so oft klemmt. Es müssen zwei voneinander unabhängige Vertrauensstellungen aufgebaut werden, und sie liegen in der Verantwortung unterschiedlicher Teams.
Cloud Connector und Identity Provider. Der Identity Provider ist das System, das die Anmeldung durchführt und bestätigt, wer der Anwender ist, in der Regel SAP Cloud Identity Services. Der Cloud Connector muss dessen Token akzeptieren und aus den mitgelieferten Angaben das Zertifikat bilden.
ABAP-System und Cloud Connector. Ihr S/4HANA-System muss ebenfalls so konfiguriert werden, dass es Ausweise dieses Ausstellers akzeptiert. Dazu gehören zwei Einstellungen. In der Transaktion STRUST, der Zertifikatsverwaltung des Systems, hinterlegen Sie das Zertifikat des Cloud Connectors in der Liste der vertrauenswürdigen Aussteller. In der Transaktion CERTRULE definieren Sie die Regel, nach der aus einem Merkmal im Ausweis der passende SU01-Benutzer ermittelt wird, üblicherweise über die E-Mail-Adresse. Beides ist einmalige Einrichtung. Die eigentliche Prüfung läuft danach bei jeder Anfrage automatisch ab.
Fehlt eine der beiden Beziehungen, sieht die jeweils andere Seite für sich betrachtet vollkommen korrekt aus. Genau daher stammen die 403-Meldungen bei scheinbar richtiger Konfiguration.
Auf der BTP richten Sie die Vertrauensstellung zum Identity Provider ein und legen die Destination mit dem Authentifizierungstyp PrincipalPropagation an. Im Cloud Connector erzeugen Sie die Zertifikate, setzen den Principal Type auf X.509 und gleichen die Vertrauensdaten des Subaccounts ab. Im ABAP-System importieren Sie das Zertifikat in STRUST, legen die Zuordnungsregel in CERTRULE an und setzen die zugehörigen Profilparameter.
Zwei Hinweise, die in unseren Projekten viel Zeit sparen:
Legen Sie zwei Destinations an. Eine mit technischem Benutzer, eine mit Principal Propagation. Im Fehlerfall sehen Sie sofort, ob die Verbindung selbst kaputt ist oder nur die Identitätsweitergabe.
Kopieren Sie Zertifikatswerte, tippen Sie sie nicht ab. Die Darstellung der Attribute ist nicht einheitlich: Der Cloud Connector zeigt das E-Mail-Attribut als EMAIL, CERTRULE zeigt stattdessen nur die technische Kennnummer. Wer hier abtippt, sucht anschließend stundenlang.
In einem Szenario ist die Entscheidung bereits gefallen: SAP Build Work Zone. Wenn Sie dort Fiori-Anwendungen aus einem S/4HANA-System einbinden, sieht der Integrationsleitfaden von SAP Principal Propagation ausdrücklich vor. Der Grund ist einleuchtend, wenn man sich die zwei Verbindungen ansieht, die Work Zone braucht: Die eine holt einmalig die Struktur der Kacheln und Rollen ab und darf mit einem technischen Benutzer laufen. Die andere ruft die Anwendung auf, wenn ein Mitarbeiter auf eine Kachel klickt. Würde diese zweite Verbindung mit einem technischen Benutzer arbeiten, sähe jeder Mitarbeiter im Launchpad dieselben Daten. Ein Launchpad ohne Principal Propagation ist damit kein Arbeitsplatz, sondern ein gemeinsamer Sammelzugang.
Allgemein gilt: Principal Propagation setzt voraus, dass es zur Laufzeit einen angemeldeten Anwender gibt. Bei einem nächtlichen Hintergrundjob oder einer reinen Systemintegration existiert diese Identität nicht. Dort ist ein technischer Benutzer die richtige Wahl, dann aber über OAuth oder ein Zertifikat abgesichert statt über ein Passwort in der Destination.
Zeigt Ihr Ziel nicht ins eigene Rechenzentrum, sondern in ein anderes Cloud-System, greift ein anderes Verfahren: OAuth2SAMLBearerAssertion. Dabei wird die Identität nicht als Zertifikat weitergereicht, sondern als signierte Nachricht, die das Zielsystem prüfen kann. Ein Cloud Connector ist dafür nicht nötig.
Aufwendiger wird es, wenn Sie über RFC anbinden statt über HTTPS. RFC ist der ältere, SAP-eigene Verbindungsweg, über den viele Bestandsanbindungen laufen. Dort unterstützt SAP nur den Weg über X.509-Zertifikate, und die Verbindung muss zusätzlich über SNC verschlüsselt sein. SNC steht für Secure Network Communication und ist die Verschlüsselung, die SAP für RFC-Verbindungen vorsieht. Wenn Ihr Zielservice auch als OData-Schnittstelle verfügbar ist, also über den normalen Webzugriff, ist dieser Weg meist der einfachere.
Die Frage lautet also nicht, ob technische Benutzer grundsätzlich schlecht sind. Sie lautet: Gibt es einen echten Anwender, dessen Rechte gelten sollen?
Nach unserer Erfahrung liegt der Aufwand selten in der Technik. Er liegt in einer unspektakulären Frage: Ist das verbindende Merkmal, meist die E-Mail-Adresse, in der Cloud und im SU01-Stammsatz flächendeckend und eindeutig gepflegt? In gewachsenen Systemen lautet die Antwort fast immer nein. Altbestände ohne Adresse, Doppeleinträge, Kennungen ohne Person dahinter.
Der zweite Punkt betrifft den Betrieb. An der Kette hängen mehrere Zertifikate mit unterschiedlichen Laufzeiten. Manche lassen sich automatisch erneuern, andere nicht. Ohne Überwachung der Ablauftermine steht die Anbindung irgendwann ohne Vorwarnung still.
Principal Propagation ist keine Zusatzfunktion, sondern die Voraussetzung dafür, dass Ihr Berechtigungskonzept auch für Cloud-Anwendungen gilt. Bei SAP Build Work Zone ist sie fester Bestandteil des Standard-Setups. Der Aufwand bleibt überschaubar, wenn die Reihenfolge stimmt und die Stammdaten sauber sind. Beides lässt sich vorab klären.
Termin buchen
Wir schauen uns Ihr Szenario an und sagen Ihnen, welches Verfahren passt, wie aufwendig die Einrichtung in Ihrem Fall wird und worauf Security und Basis bei der Abnahme achten sollten.
Schreib uns oder buche direkt ein kurzes Meeting.
