Securing APIs Across a Hybrid SAP Landscape: Authentication, Authorization and Principal Propagation

Explanation

Security is often treated as an afterthought in API design, but for an architect it must be decided at the same time as the integration pattern, because retrofitting authentication or authorization into a live API is disruptive and risky. The core decisions are: how does a caller prove its identity (authentication), what is that caller allowed to do (authorization), and does the backend need to know which end user is behind the call (principal propagation)? Authentication mechanisms commonly available in SAP landscapes include basic authentication (credentials in every call, acceptable only for low-risk internal test scenarios, not production), client certificates (mutual TLS, strong for system-to-system integration where both parties are known and stable), and OAuth2 client credentials or authorization code flows (token-based, suited to modern API gateways such as SAP Integration Suite's API Management or BTP's identity services). Architects should treat basic authentication as a legacy fallback only, because credentials are static, hard to rotate safely, and typically shared across many calls without granular audit. Authorization is a separate concern from authentication: proving who is calling does not determine what that caller may do. A well-designed API strategy defines scopes or roles at the API gateway level (for example, read-only versus write access to a given API product) so that backend systems are not the only enforcement point. This matters especially for clean core environments, where the extensibility model in S/4HANA Cloud limits how much custom authorization logic can be added directly in the backend; pushing authorization decisions into the API management layer keeps backend systems simpler and more upgrade-safe. Principal propagation is the hardest and most frequently mishandled piece. Some integrations only need system-level trust (the calling application is authorized, and the backend does not need to know which named end user triggered the call). Others require the backend to enforce end-user-specific authorizations, for example so that a manager sees different data than a regular employee even through the same API. Propagating the actual end user's identity through a gateway to backend systems (often via SAML assertion-based mechanisms or user-mapping features in BTP destinations) preserves segregation of duties defined in the backend's own authorization model, but it adds complexity: certificate or assertion lifecycle management, mapping of cloud identities to backend user IDs, and additional points of failure. Using only a generic technical/service user for every call is simpler operationally but risks bypassing backend authorization checks entirely, which can be a serious control gap in finance or HR-related APIs. Deployment-specific differences matter here and should not be generalized. In classic ECC, authentication is typically anchored in the ABAP system's own user store and trusted RFC/SNC configurations. In S/4HANA on-premise or private cloud, additional flexibility usually exists to configure custom OAuth or SAML trust relationships directly in the ABAP stack. In S/4HANA public cloud, the extensibility and configuration options for custom authentication trust are more constrained, and architects should expect to rely more heavily on standard, supported integration and identity services rather than backend-side customization; exact capabilities should be verified against current product documentation for the specific release, since this area evolves. Operationally, an API security design must also cover credential and certificate rotation, token expiry handling, and what happens when a trust relationship breaks (do calls fail loudly, or silently fall back to a less secure path?). Architects should require that every production API have a documented rotation procedure and a tested failure mode before go-live, not just a working happy-path demonstration.

Code example

# Illustrative authorization scoping model at an API gateway (conceptual, not a specific product syntax) API Product: "SalesOrderAPI-v1"Scopes defined at gateway:  - salesorder.read   (view order details)  - salesorder.create (create new orders)  - salesorder.cancel (cancel existing orders) Consumer application "MobileSalesApp":  - Granted scopes: salesorder.read, salesorder.create  - NOT granted: salesorder.cancel Consumer application "BackofficePortal":  - Granted scopes: salesorder.read, salesorder.create, salesorder.cancel # Even if both apps authenticate successfully via OAuth2 client credentials,# the gateway rejects a cancel request from MobileSalesApp before it ever# reaches the S/4HANA backend, keeping the enforcement point outside the# clean-core-restricted backend.

Real project scenario

During a security review before go-live of a partner-facing order status API, the review found that all calls used a single technical service user mapped to full authorization in S/4HANA, regardless of which partner or end user triggered the request. This meant any partner could technically query order data belonging to any other partner if they guessed an order number, because the backend had no visibility into the calling end user. The remediation required introducing OAuth2 authorization code flow with partner-specific scopes enforced at the API gateway, plus a data-filtering check keyed to the partner ID embedded in the token, before the API was allowed to go live.

Common mistakes

• Relying on basic authentication with shared credentials for production-facing APIs. • Treating authentication as sufficient security without defining separate authorization scopes. • Using a single generic technical user for all API calls when backend-level, end-user-specific authorization is actually required. • Assuming principal propagation configuration is identical across ECC, S/4HANA on-premise and S/4HANA public cloud without checking deployment-specific constraints. • Going live without a documented and tested certificate or token rotation and failure procedure.

Best practices

• Separate authentication, authorization and principal propagation as distinct design decisions for every API. • Enforce authorization scopes at the API gateway layer to keep backend systems simple, especially under clean core constraints. • Use OAuth2 or certificate-based authentication for production APIs; reserve basic authentication for non-production or clearly low-risk cases. • Decide explicitly whether an integration needs end-user-level principal propagation or can safely rely on system-level trust, based on the sensitivity of the data involved. • Require a tested credential/certificate rotation and failure-handling procedure before any production API go-live. • Verify deployment-specific authentication and trust capabilities against current documentation rather than assuming parity across ECC, on-premise and public cloud.

Interview angle

Interviewers use this topic to test whether a candidate distinguishes authentication from authorization from principal propagation, and whether they can explain the operational risk of using a single technical user versus propagating end-user identity, with a concrete example of the trade-off.