A policy is a mechanism for enforcing filters on traffic. These filters generally control authentication, access, allotted consumption, and service level access (SLA). API Manager offers a number of pre-built policies, listed in "Available Policies". You can also build custom policies. You deploy a proxy API application and apply one or more policies to control how and when a received request is forwarded to its implementation endpoint. You can set an API alert to notify you when an API request violates a policy for SLA.
For example, you can apply the Client ID Enforcement policy to govern your API version at runtime. This policy allows only authorized applications to access the deployed API implementation. Each authorized application is configured with credentials: client_id and client_secret. At runtime, authorized applications provide the credentials with each request to the API implementation. Depending on the policy configuration, the application usually needs to provide credentials in one of these ways:
In the headers of the HTTP request
In the URL as query parameters
If the credentials are valid, the policy grants access to the deployed API implementation; otherwise, the policy denies access. Credentials are granted per version. If an application obtains credentials to access v1 of the API, the application cannot use the same credentials to access v2 of the API. The application needs to explicitly request access for v2 of the API even through the application credentials are the same as those for v1.
You can apply policies to these types of APIs:
An APIkit project
For example, deploy the APIkit project to Anypoint Platform using API auto-discovery and apply a policy, as shown in the simple REST tutorial.
An API running on CloudHub
Design an API on Anypoint Platform, configure a proxy for Cloudhub, and apply a policy.
An API deployed to an on-premises or cloud-based API Gateway Runtime 2.x
An API deployed to Mule Runtime 3.8.x
In Mule Runtime 3.8.0 and later, you can enhance security through policies by using Gatekeeper. Gatekeeper disables an API until all online policies are applied.
Prerequisites for adding, removing, and applying policies are:
API Versions Owner
A declared endpoint for your API version
Use an HTTP endpoint instead of Jetty if you want to use rate-limited and throttling policies. Due to a limitation in the Jetty transport, rate-limiting and throttling policies do not work on an API that uses a Jetty inbound endpoint.
Registration of the API in API Manager is a prerequisite for policy enforcement. After you apply policies in API Manager, download the policies to API Gateway runtime or Mule 3.8.0 or later runtime through the runtime Anypoint Platform agent. Policies are stored in each runtime /policies folder.
Each runtime is configured with the client id and client secret for the API Manager account. This defines the connection between the Anypoint Platform agent and the Anypoint Platform account.
After declaring an endpoint for an API version, the following tabs on the API version details page become active: Applications, Policies, and SLA Tiers. You apply policies to an API version on the Policies tab as described in the procedure in this section. The Policies tab contains a list of out-of-the-box policies and any custom policies that your organization has added. Apply and Remove controls appear in the list.
An unavailable Apply indicates one of the following conditions:
Another applied policy fulfills the requirement (see the Fulfills column).
Another policy must be applied first (see the Requires column).
To apply a policy to an endpoint:
Click Policies to view the list of available policies for your organization.
Select individual policies to read their descriptions. When you find the one you want to apply, click Apply.
Configure the policies. A number of configuration details are required to configure some policies:
To remove policies, click Remove. To reapply the policy, reconfigure the policy. Your previous configuration is not saved.
To disable a policy, click Disable for the policy in the list of applied policies. Disabling preserves the state of the policy and data values, but stops enforcement of the policy. The Enable control appears for restarting enforcement.
You can set the order of execution of policies if you are using one of the following releases:
Studio 6.0 or later for creation, deployed to Anypoint Platform with auto-discovery
Mule 3.8 unified runtime or later
API Gateway Runtime 2.2.0 or later
CORS, Throttling, and Rate Limiting policies, respectively, have the highest precedence. If you apply these policies, you cannot set other policies at a higher level. API Manager does not let you change the precedence of CORS, Throttling, and Rate Limiting for security reasons.
To set the order of execution of applied policies:
Assuming you have signed in to Anypoint Platform, click APIs.
Click the version number of an API, the 1.0development version of the T-Shirt Ordering Service for example.
Click the Policies tab in lower part of API administration page.
The list of any applied policies and available policies appears. The list includes RAML snippets for enforcing policies in RAML.
At the top of the Applied policies list, Edit Policy Order to assign the priority.
The Edit Policy Order button is available only when the API is actively managed by an API Gateway or Mule 3.8 unified runtime.
The Reorder applied policies page appears.
Use the up and down arrows to rearrange the order of policies. For example, if you apply rate limiting, IP whitelist, and XML threat protection, you can reorder only the IP whitelist and XML threat protection policies because rate limiting takes precedence over the other policies.
Click Apply order.
Logs show the order of policies:
INFO 2015-09-28 15:37:54,214 [[leagues-rest].httpListenerConfig.worker.01] org.mule.api.processor.LoggerMessageProcessor: POLICY A INFO 2015-09-28 15:37:54,214 [[leagues-rest].httpListenerConfig.worker.01] org.mule.api.processor.LoggerMessageProcessor: POLICY B
When an Organization Owner defines the order of policy enforcement, conflicts can occur if existing API Owners have set policies on their APIs. The API Manager notifies both parties in the event of a conflict. An API Owner needs to update policies and resolve any conflicts.
The default policy polling time has been lengthened to 60 seconds as part of a global initiative to improve the performance and scalability of Anypoint Platform. MuleSoft based this change on careful examination of actual customer experiences. A minimum 60-second delay now occurs between the time you apply a policy from the UI and the time the policy goes into effect. The same delay occurs when you disable or edit a policy. You can [configure the length of the delay] using the following system property:
Configure a new value in seconds by changing the wrapper.conf file. For example:
You can apply policies to both the API and the console, or to the API only.
The configuration of the console determines how the RAML-based, auto-generated proxy is configured, as described in "Working with the APIkit Console".