In MuleSoft, a custom policy is a reusable configuration and logic set applied to APIs or integrations within Anypoint Platform. Steps to create one include defining the policy, implementing its logic, and packaging it into a reusable artifact. Deployment involves deploying the artifact to Anypoint Platform, and then applying it to APIs or integrations through configuration. Testing ensures the policy meets requirements, while monitoring assesses its performance in production. MuleSoft offers extensive documentation and community support for creating custom policies.

Lets create a ClientIdPerResource Custom Policy where we can configure List of comma separated Client IDs that will be allowed to access the resources/endpoints.

The current workflow to get a working policy for Mule 4 that can be applied in Anypoint Platform consists of:

1. Create the policy logic.
2. Bundle the policy components.
3. Share the finalized policy assets on Exchange.
4. Implement the policy across any API using API Manager.

1.Create the policy logic:

Configure Anypoint platform credentials and nexus repository credentials of your organization in settings.xml – Users>{username}> .m2 > settings.xml

Make sure you have Set up your Exchange credentials in the settings.xml file in your Maven .m2 directory” like this

2.Bundle the policy components:

Download the ClientIDPerResource project from the below link

https://help.mulesoft.com/servlet/servlet.FileDownload?file=0152T000003ayDH

We can find the zip folder at the bottom of this documentation

Extract the zip file and replace the ${orgId} with organization ID.

We can get Org ID from our organization in anypoint platform. Go to Access management> Business Group and retrive Org ID from Business group info.

Replace the ${orgId} with organization ID.

Note: Change the Maven plugin version from 3.2.7 to 3.3.5

Use the command mvn clean deploy command in command prompt and Run it to push the Custom Policy to Exchange.

The deployment gets successful. Now we can find that Custom Policy is pushed to Exchange.

Configuration of ClientIDPerResource:

1. (1) Set this expression the same as in the Client ID Enforcement policy applied to the API. If the Client ID Enforcement policy is set to #[attributes.headers[‘client_id’]] (this is the default value), then this field should be set to attributes.headers[‘client_id’] in the custom policy, without the Leading or Trailing Mule expression characters #[ ].
   (2) List of comma separated Client IDs that will be allowed to access the resources/endpoints.
   (3) Select “Apply configurations to specific methods & resources.
   (4) Set the methods and resources that will be accessed only by the list of Client IDs in (2). For example, using the regex (/api/users|/api/{user}) means that this policy will be executed on calls to /api/users and all calls to /api/{user} .
2. Apply the above configuration and wait for it to be applied to your implementation application.
3. When the custom policy is applied to the implementation, sending a request through to /api/admin with the Client ID ************************** and its Client Secret will lead to the request to be accepted and processed. Sending the request through to /api/admin with another Client ID will raise and return a 403 Forbidden error.

DISCLAIMERS AND IMPORTANT NOTES – MUST READ AND AGREE BEFORE USE

1. This illustration serves as a guide for your personal application and is not an official MuleSoft product. It’s essential to recognize this as a tailored solution rather than a supported MuleSoft offering.
2. For this custom policy, it’s advised to utilize the Client ID Enforcement policy, as the custom policy won’t authenticate the Client ID and Secret against the API Contracts. To ensure authentication precedes authorization, apply the Client ID Enforcement policy before the custom policy. Refer to the documentation for instructions on adjusting the policy sequence.

(Note: If you got unauthorized error 401, have to disable the MFA in Anypoint platform because Maven doesn’t support MFA)

Conclusion:
Developing a custom policy in Mule 4 allows for tailored API or integration behavior. However, it’s crucial to note that custom policies aren’t standard MuleSoft products and may need extra support and testing. Effective documentation, testing, and monitoring are essential for ensuring reliability in production.