As organizations embrace APIs for exchanging information with internal or external customers and partners, it’s critical not to sacrifice visibility or governance. That’s where API management comes in. API management policies can be layered on top of the implementation of the APIs to provide the governance, security and visibility required.

Out-of-the-box the Anypoint platform provides a full number of policies. Policies are grouped into categories of:

Custom Policies

While the out-of-the-box API management policies cover the majority of use cases, you may need to create a custom policy to meet your business needs. Creating a custom policy is quick and powerful. Powerful because you implement the policy on a Mule runtime where you can leverage any of the message processor components, 150+ Anypoint Connectors, enterprise integration patterns, etc. you’d use in normal integration flows. The remainder of this article will cover the steps and resources required to create and publish a custom policy template. This policy can be uploaded as a reusable policy into API manager and can be applied to any API registered with API manager.

The steps required to create a custom policy and apply it to an existing API are:

The first 10 lines of the validate-request.yaml file defines the global properties of this policy. The name, description, category,type, providedCharacteristics and requiredCharacteristics fields will be visible in the Anypoint Platform.

The configuration section, lines 11 – 23, defines the two properties, headerParam, and regexFilter, that will be set by the administrator/API Owner when this policy is applied to an API.

2. Create the policy configuration: validate-request.xml

The policy configuration file defines the implementation and execution of our custom policy. You can use any Mule application elements in the policy configuration. This configuration provides you a powerful way to implement simple to complex custom policies.

A few notes about the structure of the policy configuration file for our example:

<policy id=”{{policyId}}” name=”validateHeader”> : the {{policyId}} pulls the id value, from the policy definition YAML file. The name will be used for Analytics reports.

<expression-filter name=”expression” expression=”#[message.inboundProperties.{{headerParam}}!=null ? regex(‘{{regexFilter}}’,message.inboundProperties.{{headerParam}}) : false]”>: the expression attribute contains the MEL expression for our filter. Here we want to check if the {{headerParam}} specified at configuration/application of the policy is null on the incoming request. If it is not null, we do our regex function against the value of the incoming request to see if it matches what was specified at configuration as {{regexFilter}} variable.

<processor-chain name=”policyViolation”> : processor-chain is a common conventional component. Inside the processor-chain we can provide a linear chain of message processors which process a message in order. Which we do to 1) set the property values for the http.status, 2) content-type, and 3) payload of the http.response. What’s important is the attribute name value of policyViolation will be referenced in our message-filter, see below.

The custom Validate Header policy should now be available in your list of available policies. If the policy is not available, confirm that you are in the same business group as you were when you added the custom policy.

When you apply the policy, specify the name of the headerParam and the accepted value for that parameter. The policy will enforce that every request has the respective values you specified. In the screenshot below I’ve specified the name of the header as: mule and the accepted value as: secret!

Using the Advanced Rest Client (you can use something else to test with), test calling your API that you’ve applied the Validate Header policy too. Try calling the API in the following ways to view the results:

Without the mule header

With the mule header and the value something (or anything other than secret!)

With the mule header set and the value of secret!

Using the Advanced Rest Client and testing with an invalid header value combination you should see a 403 response code and the payload set to Access Denied! Just as we defined in the implementation of our custom policy, validate-request.xml

A correct header parameter and value combination should result in the normal payload and response of your API.

Summary

If an out-of-the-box API policy does not meet your needs or you can’t find a custom policy in the Anypoint Exchange, you can quickly create a reusable policy. Creating custom API policies in the Anypoint Platform allows you to take advantage of any of the Mule application components to implement the policy. This results in tremendous flexibility and power to meet unique business needs.

One Response to “HowTo – Custom API Policy with Anypoint Platform”

We use cookies to make interactions with our websites and services easy and meaningful, to better understand how they are used and to tailor advertising. You can read more and make your cookie choices here. By continuing to use this site you are giving us your consent to do this.

MuleSoft provides the most widely used integration platform for connecting any application, data source or API, whether in the cloud or on-premises. With Anypoint Platform®, MuleSoft delivers a complete integration experience built on proven open source technology, eliminating the pain and cost of point-to-point integration. Anypoint Platform includes CloudHub™ iPaaS, Mule ESB™, and a unified solution for API management™, design and publishing.