Policies for Mule 4
Policies applied to APIs are the same as those in the earlier release with a few exceptions.
Classloader isolation exists between the application, the runtime and connectors, and policies. To fulfill the isolation requirement, policies are self-contained and packaged to include libraries needed for execution, similar to an application.
Policies are non-blocking. You can order all policies except CORS which takes precedence over all other policies.
MEL expressions are replaced by DataWeave.
In Mule 4, classloader isolation exists between application, runtime, connectors and policies.
Other changes to policies are:
All policies are non-blocking, which is described in Mule 4 documentation.
All policies except CORS, which is executed first, can be ordered.
Resource level policy support, which was restricted to RAML-based APIs, is extended to any HTTP API.
You can distribute policies outside of the runtime, which simplifies upgrades.
Mule 4 introduces changes to the packaging, size and scope of a policy.
Notable changes to policies for governing APIs are:
API Manager now provides two HTTP Basic Authentication policies, one based on the simplest technique for enforcing access control to web resources and the other on the LDAP configuration.
If you upgrade APIs from the Jul 2017 to Nov 2017, the security manager setup information is no longer required. The policy incorporates the information.
Header propagation no longer occurs by default. You can configure header propagation for token enforcement and rate limiting policies by checking the Expose Headers checkbox.
You can configure the rate limiting policy to share the quota among the cluster nodes (default) or not.