Security in SAP Integration

Integration flows carry sensitive business data — purchase orders, employee salaries, customer payment information, and financial records. Without proper security, attackers could intercept this data in transit, impersonate legitimate systems, or inject malicious messages that corrupt SAP records. A single security breach in an integration layer can expose data from every connected system simultaneously.

Security in SAP integration works at multiple levels: who can call the integration endpoint, how data is protected in transit, how sensitive credentials are stored, and how messages are verified as authentic. Every integration you build must address all these levels.

Transport Layer Security (TLS)

The first line of defense is encrypting data in transit. TLS (Transport Layer Security) encrypts the communication channel between systems so that even if someone intercepts the network traffic, they see only unreadable encrypted bytes.

In CPI, all HTTPS endpoints automatically use TLS. When configuring receiver adapters that call external systems, always use HTTPS URLs rather than HTTP. An HTTP connection sends data in plain text — visible to anyone monitoring the network.

WITHOUT TLS:
[CPI] ──HTTP──→ data visible on network ──→ [SAP]
Everyone who can monitor the network sees the payload

WITH TLS:
[CPI] ──HTTPS──→ encrypted tunnel ──→ [SAP]
Network observers see only encrypted data, useless without the key

Authentication Methods

Authentication answers the question: "Who are you?" Before CPI processes a message, it verifies the caller's identity.

Basic Authentication

The simplest method. The caller sends a username and password encoded in Base64 inside the Authorization header. Only use Basic Auth over HTTPS — sending Base64-encoded credentials over HTTP is equivalent to sending a plain text password.

Basic Auth is simple to set up but less secure than modern alternatives because passwords can be captured if HTTPS is misconfigured, and credentials must be shared with every caller.

Client Certificate (Mutual TLS)

Both CPI and the caller present digital certificates. Each party verifies the other's certificate before the connection proceeds. This is stronger than Basic Auth because there is no shared secret — each party proves identity using a cryptographic certificate signed by a trusted authority.

Normal TLS:    Server proves identity to client
Mutual TLS:    Server AND client both prove identity to each other

OAuth 2.0

OAuth 2.0 is the modern standard for API authentication. The caller obtains a time-limited access token from an authorization server. This token is sent with each API request. When the token expires, the caller requests a new one.

The token is separate from the actual username and password. Even if someone captures a token, it only works until expiration (usually hours or days). CPI supports multiple OAuth 2.0 flows — most commonly Client Credentials (for machine-to-machine) and Authorization Code (for user-delegated access).

API Key

A long random string that acts as a password. The caller includes it in a header or query parameter. API keys are simple but have limitations — they do not expire automatically and must be rotated manually if compromised. Best used for low-risk internal integrations or when the caller cannot support OAuth.

Authorization: What Can You Access

Authentication tells CPI who is calling. Authorization tells CPI what that caller is allowed to do. CPI uses roles and role-based access control to enforce authorization.

Example: A supplier is authenticated as "Supplier-XYZ" and is authorized to submit invoices (POST to the invoice endpoint) but is not authorized to query all invoices (GET on the invoice list endpoint). The supplier's service user only has the "InvoiceSubmitter" role, not the "InvoiceViewer" role.

Securing CPI Endpoints

Every iFlow that exposes an HTTPS endpoint must be protected. CPI provides an Authorization section in the sender adapter where you select the authentication method:

• Client Certificate – Accept only callers with valid client certificates
• Basic Authentication – Require username and password
• OAuth 2.0 – Require valid OAuth token from configured identity provider
• None – No authentication required (only for internal testing, never in production)

Never leave production integration endpoints without authentication. An unprotected endpoint is an open door into your integration platform and, by extension, into every connected SAP system.

Message-Level Security

Transport security protects data while it travels across the network. Message-level security protects the message itself — even if the transport is compromised.

Digital Signatures

A digital signature proves that a message was created by a specific sender and has not been modified since. The sender uses a private key to sign the message. The receiver uses the sender's public key to verify the signature. If even one character of the message changed after signing, the verification fails.

Encryption at Message Level

PGP (Pretty Good Privacy) and XML Encryption standards encrypt the message body itself. Even if someone intercepts the encrypted message after it leaves the sender, they cannot read the content without the decryption key. CPI provides PGP Encryptor/Decryptor and XML Encryptor/Decryptor steps for this purpose.

Secure Storage of Credentials

Never store passwords, API keys, or certificates as plain text inside an iFlow. CPI provides the Security Material store for secure credential management:

• User Credentials – Store username/password pairs with an alias. Reference the alias in adapters instead of the actual credentials.
• Secure Parameters – Store any sensitive string value (API keys, tokens) with an alias.
• Keystore – Store digital certificates and private keys used for TLS and digital signatures.
• Known Hosts – Store trusted SSH host keys for SFTP connections.

When a credential changes — for example, when a password is rotated — you update it once in the Security Material store. Every iFlow that references that alias automatically uses the new credential without any iFlow changes or redeployment.

IP Allowlisting

Restrict access to CPI endpoints by source IP address. Only allow traffic from known IP addresses — your SAP system, your partner's systems, your monitoring tools. Block all other source IPs at the network level before they even reach CPI. This provides an additional layer of protection even if an attacker somehow obtains valid credentials.

Security Checklist for Every Integration

• All connections use HTTPS (TLS)
• All CPI sender endpoints require authentication (never "None" in production)
• Credentials stored in CPI Security Material, not hard-coded in iFlows
• Certificates are valid and renewed before expiry
• Only necessary permissions granted to each service user
• Error messages do not expose internal system details to external callers
• Integration endpoints are not accessible from public internet unless required