Contact Us 1-800-596-4880
  1. Homepage
  2. IDP
  3. Best Practices and Optimization

  4. Security Best Practices

Security Best Practices

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

Scenario Response

Nonce is not recognized

401 Unauthorized

Nonce is recognized but does not correlate to the specific execution ID

403 Forbidden

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:

Element Description

Identification

client_id, org_id, actionId, and actionVersion

Routing

The callback PAPI URL specific to that document type

Status

An indicator to enable or disable the record
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