Lesson 4 of 5
Authentication types and principal propagation
10 min
Listen to this lesson
A destination's Authentication property decides how the call proves who it is. SAP's documentation lists many types for HTTP destinations, including No Authentication, Basic Authentication, Client Certificate Authentication, Principal Propagation SSO, OAuth SAML Bearer Assertion, OAuth Client Credentials, OAuth User Token Exchange, OAuth JWT Bearer, OAuth Password and OAuth Technical User Propagation. You do not need all of them. Most SAP S/4HANA extension work uses a handful, and the choice depends on two questions: does the target need to know the individual user, and is the target on-premise or in the cloud?
| Authentication type | Identity sent | Typical target | Contoso use |
|---|---|---|---|
| BasicAuthentication | Technical user and password | On-premise or private API with a communication user | Fleet app reads of sales orders in CMQ and CMP |
| ClientCertificateAuthentication | Technical identity by X.509 certificate | APIs that accept certificate logon | Planned replacement for passwords on technical users |
| OAuth2ClientCredentials | The app itself, as an OAuth client | Cloud APIs with an OAuth server | Lakeside Components shipment tracking API |
| PrincipalPropagation | The signed-in user, via the Cloud Connector | On-premise systems only | Fleet supervisor actions written to SAP S/4HANA |
| OAuth2SAMLBearerAssertion / OAuth2JWTBearer | The signed-in user, exchanged for a token | Cloud systems such as SAP SaaS applications | Not used yet |
Technical users
With BasicAuthentication, the destination stores a user and password; with ClientCertificateAuthentication, a certificate. Either way, every call arrives in SAP S/4HANA as the same technical user, so the app must enforce who sees what, and SAP S/4HANA change documents show the technical user, not the person. With OAuth2ClientCredentials, the destination service fetches an access token from the target's OAuth server using a client ID and secret, and the app sends the token. Technical users suit read-only lookups, background jobs and external users unknown to SAP S/4HANA.
Principal propagation to on-premise systems
SAP describes principal propagation (also called user propagation) as forwarding the identity of a cloud user to a remote system to enable single sign-on, using a JSON Web Token (JWT) as the exchange format. For on-premise targets, the destination uses authentication type PrincipalPropagation, which is only allowed with proxy type OnPremise. The Cloud Connector validates the user's token against identity providers it trusts, then issues a short-lived X.509 certificate for that user and passes it to the back end, which maps the certificate to an SAP S/4HANA user and checks that user's own authorizations.
- User signs inGrace's fleet supervisor test user signs in to the app through the subaccount's trusted identity provider
- App callsThe app calls through destination CMC_S4HANA_PP with authentication PrincipalPropagation, passing the user's JWT
- Cloud Connector validatesChecks the token against trusted identity providers synchronized from the subaccount
- Short-lived certificateIssues an X.509 certificate whose subject follows the configured subject pattern, for example CN=${email}
- Back end trusts the Cloud ConnectorOver mutual TLS, SAP S/4HANA trusts the Cloud Connector's system certificate (STRUST and an icm/trusted_reverse_proxy parameter)
- User mappedRule-based certificate mapping (CERTRULE) finds the SAP user; that user's roles decide the result
Setting this up involves three parties. In the Cloud Connector: synchronize and mark trusted identity providers under the subaccount's Principal Propagation tab, install a system certificate for mutual TLS and a CA certificate for issuing short-lived certificates, define the subject pattern, and allow principal propagation on the access control entry. In SAP S/4HANA (Basis): trust the Cloud Connector's system certificate issuer in STRUST, set the ICM trust parameter, enable rule-based mapping with profile parameter login/certificate_mapping_rulebased and define rules in CERTRULE. In SAP BTP: the subaccount's trust configuration must be in place, because the Cloud Connector trusts the identity providers it synchronizes from there.
Cloud to cloud
When the target is another cloud system, user identity travels differently: SAP's documentation names OAuth2SAMLBearerAssertion and OAuth2JWTBearer destinations for cloud-to-cloud propagation, where the destination service exchanges the user's identity for an access token issued by the target. Trust between the two systems must be configured on both sides. Contoso does not need this yet; it will when the fleet app starts calling SAP SaaS applications on behalf of users.
What would you do?
Dan wants SAP S/4HANA change documents to show which fleet supervisor changed a delivery block from the fleet app. The developer configured BasicAuthentication with a communication user. What should change?
- Technical identities: Basic, client certificate and OAuth client credentials; the app enforces per-user rules.
- PrincipalPropagation forwards the user to on-premise systems and works only with proxy type OnPremise.
- The Cloud Connector validates the JWT, issues a short-lived X.509 certificate and the back end maps it to a user.
- Setup spans Cloud Connector (trust, certificates, subject pattern), SAP S/4HANA (STRUST, ICM, CERTRULE) and BTP trust.
- Cloud-to-cloud user propagation uses OAuth2SAMLBearerAssertion or OAuth2JWTBearer.
Check your understanding · not graded
Lesson check
1. Which proxy type is allowed for a PrincipalPropagation destination?
2. What does the Cloud Connector send to the back end for a propagated user?
3. Which transaction defines rule-based certificate mapping in an ABAP system?
4. Which authentication type fits calling a supplier's cloud API as the app itself?