Provider Bulk Sync

The Provider Bulk Sync API and its OneKey System API are delivered as a reusable, customer-hosted connector. This page describes the connector's security model and the controls you must put in place before you deploy it. Read it together with Setup.

Security Model

The connector is designed for a single-tenant, customer-hosted deployment: one customer Salesforce org and one MDM (IQVIA OneKey) credential set, with no tenant boundaries inside the runtime.

Identity and transport security are delegated to your API Gateway or API Manager, so the connector doesn't conflict with your own IAM controls. As a result, the application layer doesn't perform inbound authentication and object-level authorization. In particular, it doesn't check whether a caller owns the job it acts on. Configured Salesforce and OneKey credentials are used only for outbound calls.

The two layers differ in expected exposure:

Deployment Hardening Requirements

These controls are mandatory. The connector relies on these controls but doesn't implement them. Configure these controls before deploying the connector. Deployments that skip these controls aren't secure.

• Authenticate inbound traffic at the gateway. Apply an API Manager policy, such as OAuth 2.0, Client ID enforcement, or an equivalent mechanism so that only the trusted integration principal can access the Process API, including the GET /jobs/{jobId} and DELETE /jobs/{jobId} endpoints. Any caller that access the DELETE /jobs/{jobId} endpoint with a valid jobId can abort the corresponding in-progress sync.
• Keep the System API internal. Do not expose onekey-sys/v1 to external callers. Restrict access to internal traffic from the Process API by using a network policy, internal load balancer, or gateway routing.
• Use a single trusted principal per deployment. The security model assumes that every caller of the Process API is the same trusted integration principal. If a gateway credential is shared across multiple applications or business units, those callers can act on one another's jobs. If caller-level isolation is required, configure caller-scoped authorization at the gateway before deploying.

Job Identifier Considerations

The jobId identifies a job and is used to correlate its status, processing, and abort requests. The jobId is optional for the POST /sync endpoint. If you provide a jobId, it must be a UUID. A non-UUID value is rejected with 400 Bad Request. If you don't provide a jobId, the connector generates one. The connector returns the jobId in the response, and you can use it in the URL path for subsequent GET jobs/{jobId} and DELETE jobs/{jobId} requests.

Requiring UUID format keeps the identifier space large and unguessable, so an attacker cannot practically predict a valid jobId. This is defense in depth only — gateway-enforced caller restriction remains the primary control.

Residual Risk

Under a correctly hardened deployment, the residual risk of the abort flow is limited to availability within the single tenant. An in-progress sync job can be aborted, but aborting a sync neither reads sensitive data nor rolls back records that have already been processed. Because sync jobs can be triggered again, an aborted job can be restarted.

Production TLS and Keystore Configuration

Warning: This app includes a default Java KeyStore (JKS), <module-name>-keystore.jks, for initial deployment and local testing. The bundled JKS is an example keystore. Don't use it in production.
Before routing production traffic, replace the default JKS with a private key and certificate issued for your organization. Choose the instructions for your deployment model.

Path A: Configure TLS in a CloudHub 2.0 Private Space

Manage certificates at the platform level without changing the app package.
1. In Anypoint Platform, go to Runtime Manager > Private Spaces.
2. Select your private space, and then select the Domains & TLS tab.
3. In the TLS context configuration, upload your organization's PEM or JKS file.
4. Enter the passwords and aliases for your organization's certificate.
For more information, see Configure Private Space Domains.

Path B: Replace the Bundled JKS for Standalone, CloudHub 1.0, or Runtime Fabric Deployments

For deployment models that load a JKS from the app package, replace the bundled file before deployment.
1. Use your organization's public key infrastructure (PKI) or Java keytool to generate a JKS.
2. Open the app package, or import the app into Anypoint Studio. Go to src/main/resources/tls/.
3. Delete <module-name>-keystore.jks, and add the organization-specific JKS.
4. Update the app's configuration properties to match the new keystore. For example, update the values on the Runtime Manager Properties tab or in the YAML configuration file:
- keystore.alias: <new-alias>
- keystore.password: <new-keystore-password>
- keystore.keyPassword: <new-key-password>
5. Store passwords as secure configuration properties. Don't store unencrypted passwords in source-controlled configuration files.
6. Deploy the updated app package.
For more information, see TLS Configuration.