To establish secure connections, IBM DataPower® requires the configuration of TLS profiles (note: TLS Proxy Profile is deprecated). Depending on the flow, DataPower can act as either a client or a server.

TLS configuration often involves setting up a keystore (Identification Credentials) and a truststore (Validation Credentials), based on whether one-way or mutual TLS is needed. Let’s break down these credential types and understand where they fit in TLS client and server profiles.

TLS with Identification Credentials

TLS Server Profile: When DataPower is the TLS server (e.g., hosting an HTTPS Service). You need TLS Server Profile. It must always present a certificate to authenticate itself to the client. Therefore:

  • You use Identification Credentials to provide the server certificate to client, in this case DP’s certificate.
  • This certificate proves DataPower’s identity to the remote client.
  • You must always define Identification Credentials for a TLS Server Profile.
When DataPower is server and standard TLS is required

TLS Client Profile: When DataPower is the client (e.g., calling an HTTPS backend), you need TLS Client Profile. It may be required to present a certificate to authenticate itself — but only in mutual TLS. Therefore:

  • You use Identification Credentials to provide DataPower’s own certificate to backend server.
  • The certificate proves DataPower’s identity to the backend server.
  • You must define them if the backend server requires client (DataPower) authentication (only if mutual TLS required).
When DataPower is client and mTLS is required

TLS with Validation Credentials

TLS Server Profile: When DataPower is the server (e.g., hosting an HTTPS Service) and mutual TLS is required, you need TLS Server Profile with Validation Credentials object. DataPower will validate the client’s certificate. Therefore:

  • You use Validation Credentials to trust client certs (usually signed by a CA).
  • If mutual TLS is required, you must provide validation credentials.
When DataPower is Server and mTLS is required

TLS Client Profile: When DataPower is the client (e.g., calling an HTTPS backend) and mutual TLS is required, you need TLS Client Profile with Validation Credentials object. DataPower will validate the server’s certificate. Therefore:

  • It must validate the server’s certificate — only if mutual TLS or strict verification is needed.
  • You use Validation Credentials to trust the server’s certificate (Backend).
  • You must define them if DataPower needs to validate the server’s cert.
When DataPower is Client and mTLS is required

Real-World Example (No mTLS Required)

Let’s consider a common integration scenario to understand where TLS profiles fit in — without mutual TLS.

Imagine IBM DataPower is hosting an HTTPS service that receives requests from a frontend application. Upon receiving the request, DataPower performs some message transformations and security checks. It then initiates a secure HTTPS call to a backend service to fetch additional data or complete a transaction. Once the backend responds, DataPower again processes or transforms the response, and finally, sends the result back to the frontend.

Example

In this flow:

  • DataPower acts as a TLS server for the frontend (TLS Client), so it must use a TLS Server Profile with Identification Credentials to present its certificate.
  • When calling the backend HTTPS service, DataPower acts as a TLS client and uses a TLS Client Profile with Validation Credentials to verify the backend server’s (TLS Server) certificate.

From DataPower to backend, since mutual TLS is not required, the backend server does not request a client (DataPower) certificate, so Identification Credentials are not needed on the client side (DataPower) in this case.

Real-World Example (With Mutual TLS Enabled)

Now, let’s look at a slightly more secure variation of the same integration scenario — this time with mutual TLS.

In this enhanced security setup:

  • In this setup, DataPower acts as a TLS server when receiving requests from the frontend. It uses a TLS Server Profile configured with Identification Credentials to present its own certificate and Validation Credentials for mutual TLS, and the frontend must present a client certificate.
  • When DataPower connects to the backend service, it switches roles and acts as a TLS client. In this case, it uses a TLS Client Profile that includes Identification Credentials to present its own certificate to the backend, and Validation Credentials to verify and trust the backend’s server certificate.

This setup ensures both sides of the connection — frontend to DataPower and DataPower to backend — perform two-way certificate-based authentication, adding an extra layer of trust and security.

Conclusion

By properly configuring TLS profiles with the right Identification and Validation Credentials, IBM DataPower can securely handle communication on both ends of an integration flow. Whether using one-way or mutual TLS, understanding these components ensures your services are both trusted and protected. In this post, I’ve outlined the step-by-step setup for integrating a frontend application with IBM DataPower Gateway over TLS.

https://www.ibm.com/docs/en/datapower-gateway/10.5.x?topic=connections-tls