---
schema_version: "1"
id: f8c96a0345e35c0145a86216913feed3a0dc375e07477c8142bc9c3c01cf6bd6
title: Security Best Practices
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/idp/security-best-practices.md
canonical_url: https://docs.mulesoft.com/idp/security-best-practices
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 7aae63b28f90ac8768955704b1e067ed6836d69afd3cb973531a3b3220614293
description: MuleSoft Documentation Site
latest: true
---
---
product: IDP
---

# Security Best Practices

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Securing your IDP implementation requires an intermediary API layer to enforce granular access
control, along with governance practices for reviewer access. These measures help align with
enterprise security standards for Non-Human Accounts, Separation of Duties, and Change Management.
Native IDP access is controlled at the Anypoint Platform Business Group level, which means any
connected app within that organizational unit can invoke any document action or version.

To enforce granular access control, implement two intermediary APIs in each Business Group: an
Anypoint IDP System API (SAPI) for authorization and an Anypoint IDP Call-Back Experience API (XAPI)
for callback authentication.

## Anypoint IDP SAPI and ACL Management

The primary purpose of the SAPI is to provide a granular authorization layer and environment
separation.

### Granular Authorization via ACL

The SAPI references an Access Control List (ACL) maintained in a Postgres database such as AWS
Aurora.

- Each client (consumer) must request its own unique client credentials for the SAPI in the Anypoint
  Exchange for both production and non-production environments.

- At runtime, the SAPI extracts the `client_id` from the Okta JWT bearer token and validates it
  against the ACL.

- The SAPI ensures that the specific client is authorized for the requested `actionId` AND
  `actionVersion`.

- If not authorized, the SAPI returns a `403 Forbidden` error.

### Environment Separation (SIT to Production)

Because IDP uses a single design/runtime environment, the SAPI facilitates System Integration
Testing (SIT):

- Map SIT-specific credentials to a test version of a document action in the ACL.

- Keep production credentials locked to a stable version.

- After testing is complete, issue new production credentials and disable the SIT credentials.

### Cryptographic Nonce Generation

When the SAPI forwards a valid request to IDP, it also generates a cryptographic nonce (key), stores
the nonce in an Anypoint Object Store, and adds a cross-reference to the document’s execution ID.
This is the foundation for securing the callback.

## Anypoint IDP Call-Back XAPI

By design, the native callback URL from IDP to your solution cannot support client authentication
(OAuth) or IP restrictions. The XAPI authenticates these callback requests.

### Nonce Validation

When IDP finishes processing, it calls the XAPI. The nonce generated by the SAPI is included in this
call as a query parameter. The XAPI validates this nonce against the execution ID in the Object
Store.

### Error Handling

<table><colgroup><col> <col></colgroup><thead><tr><th>Scenario</th><th>Response</th></tr></thead><tbody><tr><td><p>Nonce is not recognized</p></td><td><p><code>401 Unauthorized</code></p></td></tr><tr><td><p>Nonce is recognized but does not correlate to the specific execution ID</p></td><td><p><code>403 Forbidden</code></p></td></tr></tbody></table>

### Downstream Delivery

If authorized, the XAPI retrieves the forward URL for the specific Process API (PAPI) from the
Postgres database and routes the status update accordingly.

## ACL Data Model and Operations

The ACL database record acts as the source of truth connecting the following:

<table><colgroup><col> <col></colgroup><thead><tr><th>Element</th><th>Description</th></tr></thead><tbody><tr><td><p>Identification</p></td><td><p><code>client_id</code>, <code>org_id</code>, <code>actionId</code>, and <code>actionVersion</code></p></td></tr><tr><td><p>Routing</p></td><td><p>The callback PAPI URL specific to that document type</p></td></tr><tr><td><p>Status</p></td><td><p>An indicator to enable or disable the record</p></td></tr></tbody></table>

> [!IMPORTANT] Limit access to the ACL table to the operations team. Implement a database trigger to
> log every Insert, Update, and Delete operation in an ACL\_Log table for auditing.

## Reviewer and Access Governance

Follow these practices to control who can access and review documents in your IDP implementation:

- Assign User Group permissions

  Use CloudHub User Groups rather than individual accounts when assigning reviewers during the
  design phase.

- Manage identity access

  Control these groups through an identity platform such as IIQ with the team manager as the
  approver.

- Restrict IP access

  Apply IP allow-listing policies to your downstream Process APIs (PAPIs) to ensure they accept
  requests only from the XAPI.

## See Also

- [Data Extraction Best Practices](https://docs.mulesoft.com/idp/data-extraction-best-practices)

- [IDP Permissions](https://docs.mulesoft.com/idp/permissions)

- [Analyzing Documents Using Pre-Built Schemas](https://docs.mulesoft.com/idp/creating-document-actions)