Introduction

When integrating SAP BTP services with SAP Sales Cloud Version 2 or SAP Service Cloud Version 2 or ESM, one of the most common requirements is ensuring that the identity of the logged-in user flows seamlessly from the source BTP application into the target SAP Cloud system. This is known as Principal Propagation.

Without principal propagation, every API call would authenticate as a technical/service user — losing all user context, audit trails, and authorization logic that depends on who is actually logged in. With it, the end user's identity is securely carried through, enabling fine-grained access control and meaningful audit logs on the SAP Sales/Service Cloud side.

This blog walks you through the complete setup using the OAuth2 SAML Bearer Assertion Flow — the recommended approach for BTP-to-SAP Sales & Service Cloud V2 connectivity.

How It Works — The Big Picture

User (logged into BTP app)

        │

        ▼

BTP Destination (OAuth2SAMLBearerAssertion)

        │  ── Generates a SAML assertion carrying the user's identity

        ▼

SAP Sales/Service Cloud V2 Token Service

        │  ── Validates the assertion against the trusted certificate

        ▼

Returns an OAuth2 Access Token (scoped to that user)

        │

        ▼

API Call executed as the propagated user

Prerequisites

• Access to your SAP BTP Cockpit (subaccount level)
• Admin access to your SAP Sales Cloud V2 / Service Cloud V2 tenant
• Ability to call REST APIs on the tenant (e.g., via Postman, Bruno, or curl)

Step 1: Download the BTP Trust Certificate

1. Log in to the SAP BTP Cockpit and navigate to your subaccount.
2. Go to Connectivity → Destinations → Download Trust (top-right area of the Destinations page).
3. A .pem certificate file will be downloaded.
4. Open the file and copy only the certificate content — the block between (but not including) the header and footer lines:

—–BEGIN CERTIFICATE—–

MIIEXzCCA0…   ← copy everything between these lines

—–END CERTIFICATE—–

Keep this certificate value handy — you'll need it in the next step.

Step 2: Configure Inbound OAuth2 Trust in SAP Sales/Service Cloud V2

SAP Sales/Service Cloud V2 needs to know about BTP as a trusted SAML assertion issuer. This is done via a dedicated IAM Service REST API on your tenant.

Important restriction: Only one OAuth2 SAML Bearer Inbound Configuration can exist per tenant.

2a. Check if a Configuration Already Exists

Send a GET request to check the current state:

GET <Your-Tenant-Host-URL>/sap/c4c/api/v1/iam-service/oauth2InboundConfiguration

• If a configuration exists with the same BTP certificate → you can reuse it as-is.
• If a configuration exists with a different certificate → update it (Step 2b).
• If no configuration exists → create a new one (Step 2c).

2b. Update an Existing Configuration (PUT)

PUT <Your-Tenant-Host-URL>/sap/c4c/api/v1/iam-service/oauth2InboundConfiguration/<id>

Content-Type: application/json

{

    “id”: “<existing Id found in Step 2a>”,

    “clientAppName”: “<A meaningful name, e.g. BTP-SalesCloud-Trust>”,

    “certificate”: “<Certificate content from Step 1>”

}

2c. Create a New Configuration (POST)

POST <Your-Tenant-Host-URL>/sap/c4c/api/v1/iam-service/oauth2InboundConfiguration

Content-Type: application/json

{

    “id”: “<BTP Subaccount UUID (This is to easily identify or you can provide your own UUID v4 format>”,

    “clientAppName”: “<A meaningful name, e.g. BTP-SalesCloud-Trust>”,

    “certificate”: “<Certificate content from Step 1>”

}

2d. Save the Response Values

A successful POST or PUT returns a JSON response like this:

{

  “value”: {

    “id”: “…”,

    “grantType”: “SAML2_BEARER”,

    “nameIdType”: “EMAIL”,

    “spEntityId”: “…”,

    “audience”: “<AUDIENCE>”,

    “tokenServiceUrl”: “<TOKEN_URL>”,

    “clientId”: “<CLIENT_ID>”,

    “scopes”: [“<SCOPE_ID>”],

    “clientAppName”: “…”,

    “certificate”: “…”

  }

}

Note down these four values — you'll need them in Step 3:

Field Used As

Step 3: Create the BTP Destination

Now configure a destination in your BTP subaccount that uses the inbound configuration values you just collected.

1. Go to SAP BTP Cockpit → Subaccount → Connectivity → Destinations → New Destination.
2. Fill in the following fields:

Property Value

The nameIdFormat value tells the system to use the user's email address as the SAML NameID — this is how the user identity is matched on the SAP Sales/Service Cloud V2 or ESM side.

Step 4: Configure Trusted Domains in SAP BTP Authorization & Trust Management

As a final step, ensure that your SAP Sales/Service Cloud V2 tenant domain is registered as a trusted domain in SAP BTP's Authorization and Trust Management service (XSUAA/SAP Cloud Identity Services).

Refer to the official SAP documentation: Configure Trusted Domains for SAP Authorization and Trust Management Service.

This ensures that SAML assertions issued by BTP are only accepted by explicitly trusted target systems — an important security boundary.

Summary

Here's a quick recap of the end-to-end setup:

Step 1 → Download BTP X.509 Trust Certificate

Step 2 → Register certificate as Inbound OAuth2 Config on SAP Sales/Service Cloud V2

Step 3 → Create OAuth2SAMLBearerAssertion Destination in BTP using response values

Step 4 → Register SAP Sales/Service Cloud V2 domain as trusted in BTP Auth & Trust

Once complete, any BTP application or service using this destination will automatically propagate the logged-in user's identity to SAP Sales/Service Cloud V2 — without requiring users to re-authenticate or sharing technical credentials.

Key Takeaways

• Principal Propagation bridges the identity gap between BTP and SAP Sales/Service Cloud V2, preserving the real user context across systems.
• The trust is certificate-based — BTP's signing certificate is registered directly in the SAP Sales/Service Cloud V2 IAM service.
• The fixed UUID (34f8b9d2-78c2-4617-bcf2-6eb36403c667) is a well-known system identifier for this configuration — don't change it.
• Only one inbound configuration is allowed per tenant, so manage it carefully across teams.
• User matching relies on email address as the SAML NameID — ensure users exist with the same email in both systems.

Share to your colleagues or Have questions or ran into issues during the setup? Drop them in the comments below.