About Policies (Nov 2017 and Jul 2017)
A policy extends the functionality of an API and enforces certain capabilities such as security. A policy can control access and traffic. For example, a policy can generally control authentication, access, allotted consumption, and service level access (SLA). 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.
An API running on CloudHub
Design an API on Anypoint Platform, configure a proxy for Cloudhub, and apply a policy.
An API deployed to a private or cloud-based Mule Runtime 3.8.x or later
An API deployed to API Gateway Runtime 2.x
API Manager provides a number of 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.
By default, a policy applies to the entire API, filtering traffic requests to every resource and method.
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.
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 instance (Nov 2017 API Manager) or version (Jul 2017). If an application obtains credentials to access v1/instance 1 of the API, the application cannot use the same credentials to access v2/instance 2 of the API. The application needs to explicitly request access for v2/instance 2 of the API even through the application credentials are the same as those for v1/instance 1.