SAP Keystore and Credentials

Every integration connects to systems that require authentication. These connections use passwords, API keys, OAuth secrets, or certificates. Storing these secrets safely — where iFlow code cannot expose them and unauthorized users cannot read them — is a fundamental requirement of professional integration development.

CPI provides the Security Material section for all secure storage. You access it through Monitor → Manage Security. This area is the locked safe of your CPI tenant. Secrets go in once and are referenced by alias. The actual secret value never appears in iFlow configuration files.

Types of Security Material

User Credentials

Stores a username and password pair under an alias. Used when connecting to systems that require HTTP Basic Authentication.

Example:
  Alias: SAP_S4HANA_PROD_BASIC
  User:  CPI_SERVICE_USER
  Password: *** (stored encrypted, never displayed again)

In iFlow HTTP Adapter:
  Authentication: Basic
  Credential Name: SAP_S4HANA_PROD_BASIC

The iFlow references the alias "SAP_S4HANA_PROD_BASIC". CPI looks up the actual username and password at runtime. If the password changes, you update the User Credential artifact — no iFlow changes needed.

Secure Parameters

Stores a single sensitive string value under an alias. Used for API keys, subscription keys, or any single-value secret. Access in iFlows via the expression {{SecureAlias}} in Externalized Parameters, or the SecureAlias lookup in Groovy scripts.

OAuth2 Client Credentials

Stores the full OAuth 2.0 client credentials configuration for machine-to-machine calls:

• Token Service URL (where to get tokens)
• Client ID
• Client Secret
• Scope (optional)

When an iFlow's adapter references an OAuth2 credential alias, CPI automatically fetches tokens and refreshes them before expiry — all transparently.

Keystore (Certificates and Keys)

The keystore holds digital certificates and private keys. It contains two types of entries:

• Key Pairs – A private key plus its corresponding public certificate. Used for signing outbound messages and for mutual TLS where CPI presents its own certificate.
• Certificates – Public certificates of trusted external parties. Used to validate incoming signatures and to trust TLS connections to external systems.

Keystore Operations

Importing a Certificate

When an external system provides you with their public certificate (for TLS trust or signature verification):

1. Navigate to Monitor → Manage Security → Keystore
2. Click Add → Certificate
3. Upload the .cer or .pem certificate file
4. Give it an alias (e.g., "SUPPLIER_XYZ_CERT")
5. Click Deploy

CPI now trusts TLS connections presenting this certificate and can verify message signatures made with the corresponding private key.

Importing a Key Pair

A key pair (private key + certificate) is needed when CPI must prove its own identity:

1. Obtain the PKCS#12 (.p12) or JKS keystore file from your security team or CA
2. Navigate to Keystore → Add → Key Pair
3. Upload the file and provide its password
4. Select which entry to import if the file contains multiple
5. Set the alias and deploy

Generating a Key Pair in CPI

For new integrations, generate the key pair directly in CPI rather than importing one. This keeps the private key inside CPI — it is generated there, stored there, and never exported. This approach prevents the private key from traveling across networks or being stored in spreadsheets.

Keystore → Add → Key Pair → Generate
  Algorithm: RSA
  Key Size: 2048 or 4096
  Alias: CPI_SIGNING_KEY
  Common Name: cpi.yourcompany.com
  Validity: 2 years

After generating, export only the public certificate and share it with partners who need to verify your signatures. The private key remains locked inside the CPI Keystore.

Known Hosts File

When connecting to SFTP servers, SSH verifies the server's identity using its host key. The Known Hosts file stores the fingerprints of trusted SFTP server host keys.

Without Known Hosts:
CPI refuses SFTP connections to unknown servers (correct security behavior)

Adding a known host:
Monitor → Manage Security → Known Hosts → Add
  Upload the known_hosts file containing the server's host key fingerprint

Get the host key fingerprint from your SFTP server administrator. Never skip this step by disabling host key verification — it makes SFTP connections vulnerable to man-in-the-middle attacks.

PGP Keys

For PGP encrypted file exchange, CPI stores PGP keys in the PGP Keys section:

• Secret Keys – Your PGP private keys. Used to decrypt files partners encrypt to you.
• Public Keys – Partners' PGP public keys. Used to encrypt files you send to partners.

Access Control for Security Material

Not everyone in your organization should be able to read or modify security material. CPI enforces role-based access:

• The AuthGroup_IntegrationDeveloper role allows viewing security material but not reading secret values
• The AuthGroup_Administrator role allows adding, editing, and deleting security material

Developers can reference aliases in iFlows without seeing the actual password. Administrators manage the underlying secrets. This separation of duty is a security best practice — developers do not need to know production passwords to build integrations.

Credential Rotation Procedure

When a service account password changes or a certificate expires, follow this safe rotation procedure:

Step 1: Create NEW credential artifact with updated value
        Alias: SAP_S4_PROD_BASIC_V2

Step 2: Update iFlows to reference the new alias (in non-prod first)

Step 3: Test connections with new credential

Step 4: Deploy updated iFlows to production

Step 5: Verify production integrations work with new credential

Step 6: Only then, delete old credential artifact
        Alias: SAP_S4_PROD_BASIC (old - safe to remove now)

This sequence ensures continuous operation throughout the rotation. The old credential keeps working until the new one is confirmed working everywhere. No rush, no downtime.

Certificate Expiry Monitoring

The CPI Keystore displays the expiry date of every certificate. Build a process to review expiring certificates at least monthly. Many teams set up a separate monitoring iFlow that reads certificate metadata and sends an alert when any certificate expires within 60 days.