Security architecture: identity and trust

An extension that spans SAP S/4HANA and SAP BTP crosses at least two security domains. Users must sign in once, be known in both places, and hold the right authorizations in each. Calls between the systems must be trusted, encrypted and, where it matters, carry the identity of the real user. Getting this right is mostly a matter of choosing well-known patterns early and documenting them.

Three pillars of identity and access

SAP's identity and access management reference architecture names three pillars: authentication and single sign-on, the identity lifecycle, and authorization. SAP Cloud Identity Services are positioned as the central identity interface for SAP cloud applications. Single sign-on uses open standards such as SAML 2.0 and OpenID Connect; the identity lifecycle (creating, changing and, importantly, deleting users and groups) uses SCIM 2.0 replication. Authorization stays domain-specific: an SAP S/4HANA business role and an SAP BTP role collection are designed differently, and a user needs both to use an extension that spans them.

Carrying identity into SAP S/4HANA

When a BTP app calls SAP S/4HANA, the back-end call needs an identity. Two patterns dominate. With principal propagation, the identity of the signed-in cloud user is forwarded to the remote system, so SAP S/4HANA applies that user's own authorizations and logs that user's name. SAP's connectivity documentation describes two variants: cloud to on-premise through the Cloud Connector with a destination of authentication type PrincipalPropagation, and cloud to cloud with authentication types such as OAuth2SAMLBearerAssertion or OAuth2JWTBearer. A JSON Web Token carries the user information. With a technical user, the app calls the back end as one system identity and must enforce data restrictions itself.

Contoso uses both. Its internal key users' BTP apps propagate the user, so Maria's sales authorizations in CMP apply. The fleet order status app serves Great Lakes Fleet Services staff, who have no SAP S/4HANA users. It therefore authenticates them through SAP Cloud Identity Services, calls CMP with a technical user that can only read sales order status through a released API, and filters every response to the customer number tied to the signed-in user's group. That filter is the security control, so it has its own tests.

Connectivity and trust

Systems not exposed to the internet are reached through the Cloud Connector, which runs in the customer's network as a reverse invoke proxy: it opens the connection outward to SAP BTP, so no inbound firewall ports are needed, and it exposes only the specific systems and resources the administrator allows. It records audit logs of inbound traffic and configuration changes and can run in a high-availability setup. SAP's secure setup recommendations include changing the initial administrator password at once, using LDAP for administrator access, limiting operating system access to a few administrators and running the machine for the connector alone. Where workloads run on a supported hyperscaler, SAP Private Link service can keep traffic between SAP BTP and those workloads off the public internet; it currently supports the Cloud Foundry and Kyma runtimes.