SAP

Prüfen

Füge ein XSUAA- oder IAS-Token, eine xs-security.json, eine xs-app.json, einen Service-Key, eine Destination (JSON oder Properties) oder ein Anmeldeticket (MYSAPSSO2) ein. AuthTailor prüft es auf die üblichen Fehler.

1. Die vier Bereiche: Prüfen, Warum 403?, Abläufe, Lernen.
2. Erkannt: hier XSUAA-/IAS-Token. Möglich sind auch xs-security.json, xs-app.json, Service-Key, Destination und Anmeldeticket (MYSAPSSO2).
3. Die Karte mit derselben Token-Anatomie wie in Tokens und SAML, dazu SAP-Claims wie origin, zid und xs.rolecollections.

Service-Keys und Destinations bleiben nur im Arbeitsspeicher. Secrets zeigt AuthTailor maskiert an, nichts wird gespeichert oder gesendet.

xs-security.json

1. Erkannt: xs-security.json.
2. Die Befunde – hier ein Platzhalter im Host der redirect-uris, ein localhost-Eintrag für die Entwicklung und lange Token-Laufzeiten.

Darunter stehen die Felder – Scopes, Rollenvorlagen, Rollen-Collections, redirect-uris, token-validity – und ein Vorschlag für eine sicherere oauth2-configuration zum Kopieren. Prüfe die Werte vor dem Einsatz.

Zum Ausprobieren gibt es die Beispiele XSUAA-Token, xs-security.json, xs-app.json und Destination.

Warum 403?

Ein 403 vom App Router oder einem CAP-Service heißt meist: Der Scope steht nicht im Token. Füge das Token und das ein, was die App erwartet – du siehst genau, was fehlt und wo es zugewiesen wird.

1. Das Token.
2. Erwartete Scopes, Rollen oder Rollen-Collections – getrennt durch Komma, Leerzeichen oder Zeile. $XSAPPNAME versteht AuthTailor.
3. Was fehlt, jeweils mit Abhilfe: Rolle in eine Rollen-Collection aufnehmen, dem Benutzer oder seiner IdP-Gruppe zuweisen, dann ab- und neu anmelden.

Warum sehe ich bei der Integration Suite kein JWT?

Integration Suite, Build Work Zone und viele andere Apps auf SAP BTP melden dich über einen SAP App Router an. Der App Router ist ein vertraulicher Client: Er löst den Code auf dem Server bei XSUAA ein und gibt dem Browser nur ein Sitzungs-Cookie. Das JWT bleibt auf dem Server. Kein Browser und keine Extension sieht es – auch ein HAR aus den DevTools nicht, und Auch Bearer-Tokens hilft nicht, weil die App ihre Aufrufe mit dem Cookie macht.

Statt eines Tokens zeigt AuthTailor im Mitschnitt oder im eingefügten HAR unter Über den ganzen Ablauf den Hinweis SAP App Router: Das Token bleibt auf dem Server – mit dem, was der Mitschnitt trotzdem verrät:

Fehlendes state und PKCE sind beim App Router SAP-Standard: Ziel und Rücksprung hält er in eigenen, signierten Cookies, und den Code löst er mit Client-Secret oder Zertifikat ein. AuthTailor zeigt das deshalb nur als Hinweis und nicht als ernste Schwäche – ebenso fehlendes PKCE, wenn XSUAA beim IdP anfragt. Bei anderen Apps bleibt die Warnung.

So suchst du weiter:

• Rollen-Collections des Benutzers: im BTP-Cockpit unter Subaccount → Security → Users.
• Für einen 403 bei einem API-Aufruf: ein Token aus einem Service-Key holen (Client Credentials), einfügen und mit Warum 403? gegen die erwarteten Scopes prüfen.
• Den Ablauf verstehen: BTP-Anmeldung: App Router → XSUAA → IAS → Firmen-IdP unter Abläufe.

Fehler zwischen IAS, Firmen-IdP und BTP finden

Hinter dem App Router reicht XSUAA die Anmeldung an den IAS weiter, und der IAS oft an den Firmen-IdP. Wie viel davon der Mitschnitt zeigt, hängt vom Protokoll jedes Wegs ab:

• SAML: Die Assertion reist durch den Browser. Den Schritt mit der SAMLResponse öffnen – Attribute, NameID, Signatur und Gültigkeit stehen dort.
• OIDC: Durch den Browser reist nur der Code; die empfangende Seite löst ihn auf dem Server ein. AuthTailor nennt diese Wege unter Über den ganzen Ablauf im Hinweis OIDC zwischen den IdPs: Auch diese Tokens bleiben auf dem Server, etwa XSUAA → <tenant>.accounts.ondemand.com oder IAS → <Firmen-IdP>.

Für die OIDC-Wege stehen die Fehler in den Protokollen der IdPs:

• IAS ↔ Firmen-IdP und IAS ↔ BTP: IAS-Administrationskonsole → Monitoring & Reporting → Troubleshooting Logs, nach Benutzer und Zeit filtern.
• Firmen-IdP: dessen Anmeldeprotokolle, bei Microsoft Entra ID die Sign-in logs mit dem AADSTS-Code.
• BTP: zugeordnete Gruppen und Rollen-Collections im BTP-Cockpit unter Security → Users.

Meldet AuthTailor Anmeldung über den SAP ID Service, nicht über den eigenen IAS, lief die Anmeldung über den Standard-Trust sap.default auf accounts.sap.com. Dann waren der eigene IAS und der Firmen-IdP gar nicht beteiligt. Unter Security → Trust Configuration den Origin-Key des IAS-Trusts nachsehen, neu anmelden und auf der Anmeldeseite diesen IdP wählen. Der Benutzer muss mit diesem Origin angelegt sein. Soll nur der eigene IdP erscheinen, beim Default Identity Provider „Available for User Logon“ ausschalten; im App Router erzwingt eine Route ihn mit "identityProvider": "<Origin-Key>".

Abläufe

Fünf Abläufe auf SAP BTP als Sequenzdiagramm: wer mit wem spricht, was mitreist und wo es schiefgeht.

1. Die Auswahl: BTP-Anmeldung: App Router → XSUAA → IAS → Firmen-IdP, IAS direkt (OIDC) mit Entra ID dahinter, Principal Propagation zu S/4HANA on-premise, OAuth2SAMLBearerAssertion (SuccessFactors, S/4HANA Cloud) und Fiori/Gateway: CSRF-Token, sap-client und Sitzung.
2. Das Diagramm: gestrichelt über den Browser, durchgezogen von Server zu Server, gepunktet lokal.
3. Das Detail zum gewählten Schritt mit dem, was mitreist. Zurück, Weiter und Abspielen gehen den Ablauf durch.

Die allgemeinen Abläufe für SAML, OAuth und OIDC stehen in Lernen.

Lernen

Wie Anmeldung und Berechtigungen auf SAP BTP funktionieren – in sechs Kapiteln, dazu ein Glossar und die SAP-Fehler.

1. Ein Kapitel: kurz erklärt, mit den typischen Brüchen.
2. Zum Ablauf öffnet den passenden Ablauf in Abläufe.

Die Kapitel: XSUAA, IAS und der Firmen-IdP · Scopes, Rollenvorlagen, Rollen-Collections · Principal Propagation und der Cloud Connector · Anmeldetickets (MYSAPSSO2) und Assertion-Tickets · Fiori und Gateway: CSRF-Token, sap-client, sap-usercontext · Destinations ohne Überraschungen. Unter SAP-Fehler durchsuchst du die bekannten Fehler von XSUAA, SAP Cloud Identity Services und SuccessFactors mit Ursache und Abhilfe.