All contents © MuleSoft, LLC
SEGURIDAD FUERTE COMO
EL VINAGRE DE JEREZ.
POLÍTICAS DE SEGURIDAD
EN API MANAGER
27 de Octubre 2022
NTTDATA. Paseo de la Castellana 77, planta 12 (salas de 6 a 9)

Meetup Mulesoft – API Manager demo
Octubre 2022

All contents © MuleSoft, LLC
API Management
Fuente: What is API Management? | MuleSoft
API management is the process of designing,
publishing, documenting and analyzing APIs in a
secure environment. Through an API
management solution, an organization can
guarantee that both the public and internal APIs
they create are consumable and secure.

All contents © MuleSoft, LLC
API GATEWAY
API MANAGER
API PORTAL
Componentes
DESCUBRIMIENTO
EJECUCIÓN
GESTIÓN

All contents © MuleSoft, LLC
MULE GATEWAY FLEX GATEWAY
MULE RUNTIME
API GATEWAY API GATEWAY
API
MANAGE
R
API
MANAGER
SERVICE MESH
MICRO
SIDECAR
API GATEWAY
API
MANAGER
CONSUMIDORES
BACKEND/MICRO/API
MODO CONECTADO

All contents © MuleSoft, LLC
MULE GATEWAY DETAIL

All contents © MuleSoft, LLC
FLEX
GATEWAY
MULE
GATEWAY
SERVICE
MESH
Basic Authentication: LDAP
✓ ✓ ✓
Allows access based on the basic authorization mechanism, with user-
password defined on LDAP
Basic Authentication: Simple ✓ ✓ ✓
Allows access based on the basic authorization mechanism, with a single
user-password
Client ID Enforcement ✓ ✓ ✓ Allows access only to authorized client applications
Cross-Origin Resource Sharing (CORS) ✓ ✓ Enables access to resources residing in external domains
Detokenization ✓ (*) Returns a tokenized value to its original value
Header Injection ✓ ✓ Adds headers to a request or a response
Header Removal ✓ ✓ Removes headers from a request or a response
HTTP Caching ✓ ✓ Caches HTTP responses from an API implementation
IP Allowlist ✓ ✓ Allows a list or range of specified IP addresses to request access
IP Blocklist ✓ ✓
Blocks a single IP address or a range of IP addresses from accessing an API
endpoint
JSON Threat Protection ✓ Protects against malicious JSON in API requests
JWT Validation ✓ ✓ ✓ Validates a JWT
Message Logging
✓ ✓
Logs custom messages using information from incoming requests,
responses from the backend, or information from other policies applied to the
same API endpoint
OAuth 2.0 Access Token Enforcement Using Mule OAuth
Provider
✓ Allows access only to authorized client applications
OpenAM OAuth 2.0 Token Enforcement ✓ Allows access only to authorized client applications
OpenID Connect Access Token Enforcement ✓ ✓ ✓ Allows access only to authorized client applications
PingFederate OAuth 2.0 Token Enforcement ✓ Allows access only to authorized client applications
Rate Limiting ✓ ✓ ✓
Monitors access to an API by defining the maximum number of requests
processed within a period of time
Rate Limiting: SLA-based ✓ ✓ ✓
Monitors access to an API by defining the maximum number of requests
processed within a timespan, based on SLAs
Spike Control ✓ ✓ Regulates API traffic
Transport Layer Security (TLS) ✓ Enables HTTPS
Tokenization ✓ (*) Transforms sensitive data into a nonsensitive equivalent, named token
(*) Solo en Runtime Fabric

All contents © MuleSoft, LLC
Felipe Pérez González
Technology and Advanced Solutions | Digital Architecture
Expert Architect
felipe.perez.gonzalez@nttdata.com | M: +34 616694123
MuleSoft Custom Policies – Mule 4

All contents © MuleSoft, LLC
Agenda
9
1. Introduction
2. Custom Policy structure
3. Custom Policy modes
4. YAML configuration file
5. Flow execution order
6. Development
7. Deployment into Exchange
8. Demo
9. Highlights
10. References

All contents © MuleSoft, LLC
1. Introduction
10
¿What is a Custom Policy?
● Is a policy that we can add to the runtime to extend
the functionality of Mule applications.
● Is a policy that we can apply to the Mule application
at the runtime level in CloudHub.
● Is a policy that is used to apply functionality to
requirements not covered by out-of-the-box Mule
policies, extending its functionality or defining new
ones.

All contents © MuleSoft, LLC
2. Custom Policy structure
11
Basic XML structure
● <http-policy:proxy name=“{{{policyId}}}-custom-policy”>
 Indicates the policy definition beginning of the logic to
execute in a custom policy.
● <http-policy:source> or <http-policy:operation> 
Indicates the policy definition execution model that will
follow the implementation of the custom policy (source or
operation)
● <http-policy:execute-next/>  Indicates at which point
of the policy definition implementation should jump to the
Mule application flow or when the "http request" call is
made, depending on the execution model.

All contents © MuleSoft, LLC
Source Policies
● The implementation executed before and after the API Mule Application implementation
flow.
● The changes over the Mule messages will only be propagated if they are made “after”
the <http-policy:execute-next/>.
Operation Policies
● The implementation executed before and after an “http:request” inside the API Mule
Application implementation flow.
● The changes over the Mule messages will only be propagated if they are made “before”
the <http-policy:execute-next/>.
Propagation can also be enabled using the attribute
propagateMessageTransformations=“true” in the policy definition execution
model (source or operation), independently of the location of the Mule messages
made.
3. Custom Policy modes
12
Source Policies VS Operation Policies

All contents © MuleSoft, LLC
● id: Unique ID within your organization of the policy.
Mandatory
● name: User friendly name that is used for displaying the
policy name in API Manager’s UI. Mandatory
● supportedPoliciesVersion: Deprecated property. Value
should be set to ‘>=v1’ for now. Mandatory
● description: Description of what the policy does. Also
used in API Manager’s UI. Mandatory
● category: Category to which the policy belongs. Used to
group and filter policies in API Manager’s UI, any String
value is valid. Mandatory
● violationCategory: Deprecated property. Value should
be set to ‘system’. Mandatory
4. YAML configuration file
13
Custom Policy YAML configuration file structure
● type: Value used by the Edge to show metrics about
different types of policy violations. Mandatory
● resourceLevelSupportted: Whether resource level
pointcuts should be enabled when applying the policy.
Mandatory
● standalone: Deprecated property. Value should be set to
‘true’. Mandatory
● identityManagment: Whether policy requires information
about an identity management that is configured to the
API’s Organization. Optional
● configuration: Where the policy parameters are defined.
Every parameter listed here will be rendered as an
expected user input in API Manager’s UI. It expects an
array of values. Mandatory

All contents © MuleSoft, LLC
● propertyName: Internal name of the parameter. Must be unique
within the policy.
● name: User friendly name of the parameter. Used for displaying in
API Manager’s UI.
● description: Description of the parameter. Also, used for
displaying in API Manager’s UI.
● type: Type of the parameter.
● defaultValue: Default value for the parameter.
● optional: Whether is mandatory for the user to enter this value or
not.
● sensitive: Whether this property should be masked when entering
in API Manager’s UI.
● allowMultiple: Whether multiple values should be allowed for this
parameter.
4. YAML configuration file
14
Custom Policy YAML configuration file policy parameter’s structure
Parameter types
● string: Any string expected.
● expression: A DataWeave expression
starting with #[ and finished with ] is expected.
● boolean: true or false.
● int: A number is expected. This type requires
additional properties:
minimumValue: Minimum value allowed for
the parameter.
maximumValue: Maximum value allowed
for the parameter.
● radio: One value of a group of options. This
type requires additional properties:
options:
- name: Name for displaying in the UI
value: internal value used in the policy
● keyvalues: Collection of Key-Value pairs.

All contents © MuleSoft, LLC
Policy A has order 1 and Policy B has order 2.
5. Flow execution order
15
Source Policy VS Operation Policy
<http-policy:proxy name="policy-A">
<http-policy:source>
<A1 />
<http-policy:execute-next/> <!-- API Flow
-->
<A2 />
</http-policy:source>
</http-policy:proxy>
<http-policy:proxy name="policy-B">
<http-policy:operation>
<B1 />
<http-policy:execute-next/> <!-- API Flow
-->
<B2 />
</http-policy:operation>
</http-policy:proxy>
API Invoke > Listener > A1 > API Flow > B1 > HTTP Request > B2 > API Flow > A2 > API Response
A1 B1 B2
A2
API Invoke
API Response

All contents © MuleSoft, LLC
mvn -Parchetype-repository archetype:generate
-DarchetypeGroupId=org.mule.tools
-DarchetypeArtifactId=api-gateway-custom-policy-archetype
-DarchetypeVersion=1.2.0
-DgroupId=${orgId}
-DartifactId=${policyName}
-Dversion=0.0.1-SNAPSHOT
-Dpackage=mule-policy
6. Development
16
Create Custom Policy – Maven Archetype
● Maven Archetype: Is the easiest way to generate a custom policy. Needs the “.m2/settings.xml” of maven well
configured.
It generates a basic policy that sets the returned HTTP Response payload to a “Hello World!”
message.
Data set-up:
● ${orgId}: with the Anypoint Platform Organization Id where
the policy will be uploaded.
● ${policyName}: with the desired name for the custom
policy.
● policyDescription: A brief description of your policy.
● policyName: The identifier name of your policy.
Project structure
● pom.xml:
o groupId: the organization ID used in the archetype.
o mule-policy: the packaging mode for the plugin.
o distributionManagement: pointing to user’s
Exchange.
o mule-maven-plugin: to package the policy into a jar.
o maven-deploy-plugin: to deploy the jar and the
YAML in Exchange.
● mule-artifact.json: exists for the mule-maven-plugin.
This is the same file you need for Mule applications.
● my-custom-policy.yaml: renders the policy
configuration UI. If this file is not provided, the policy
won’t be able to be applied through API Platform’s UI.
● template.xml: where the logic of the policy and Mule
configuration is defined. It could handle any “mule-
application” logic.

All contents © MuleSoft, LLC
6. Development
17
HandleBars
● HandleBars are a templating engine for resolving the configurable parameters of the policy in the YAML configuration
file and implementing semantic logic, such as conditionals in the custom policy logic.
● Each policy parameter defined in a YAML configuration file can be referenced from the policy logic implementation
using curly brackets.
● Simple primitive types (String, Expression, Radio, Int, and Boolean) can be referenced as: {{{myproperty}}}
● Complex types (Keyvalues) can have inner propertie that can be referenced as: {{{keyvalue.key}}} and
{{{keyvalue.value}}}
● The reserved HandleBars properties that can be referenced are:
o {{{policyId}}}: id of the policy, useful for logging or naming a policy
o {{{isWsdlEndpoint}}}: indicates whether the API where the policy is being applied is a WSDL API.

All contents © MuleSoft, LLC
7. Deployment into Exchange
18
Maven Configuration
The deployment into Exchange as an Asset to manage the policy and assign
it into any API Intance in the API Manager is as simple as launch the following
Maven command: “mvn clean package deploy”.
● Exchange Contributors role in your organization to upload the Custom
Policy as an Asset in Exchange.
● pom.xml: Needs to get configured the following parameters:
o <groupId>  Your organization Id.
o <packaging>  “mule-policy”.
o <properties>  “exchange.url” and “mule.maven.plugin.version”.
o <repository>  The exchange server repository of your organization.
o <distributionManagement>  The exchange server as the distribution
management repository.
o <build> <plugins>
 Mule Maven plugin: Verifies the correct policy package.
 Maven Deploy plugin: Uploads the policy JAR and YAML files to
Exchange.
o <pluginRepositories>  Build plugins repository.
● .m2 > settings.xml: Your Exchange credentials.

All contents © MuleSoft, LLC
9. Highlights
19
Tips and Learned Lessons
● A Mule 4 Custom Policy could behave with small changes as a Mule Application.
● The same policy could have both custom policy modes in the logic implementation.
● Always update the “pom.xml” version for a new asset, do not delete the previous uploaded asset in Exchange and
uploaded again with the same version.
● Class isolation:
o Any plugin, library, or resource visible to the application is also visible to any policy applied to that application.
o A policy can define any number of variables that can be accessible only between policy blocks.
 A variable defined in a “http-policy:source” block is available in a subsequent “http-policy:operation” block in the
same policy. They are not available to other polices and to the application.
o If a policy and an application use the same dependency but with different versions, the application’s dependency
version will be used by the policy.
 Always exclude the “mule-http-connector” to avoid inconsistency between versions.
 To uses some custom code (Java, Python, Groovy …) encapsulate it in a custom component and upload it to
Exchange. Then import this custom code component in the custom policy to avoid incompatibilities with the
Applications.
● The “mule-artifact.json > minMuleVersion” property should not be more than 2 minor version of difference with the
runtime version.
● There is no need to configure the pointcut element in Mule 4, this information about the API instance, method and/or
resource on which the custom policy operates is provided by API Manager when a policy is applied.
o Each custom policy is treated independently, even when there are several custom policies of the same asset
applied to the same instance of an API, but to different methods and/or resources.

All contents © MuleSoft, LLC
10. References
20
Some bullets of interest
● HTTP Policy Transform Extension: simplifies the modification of HTTP requests and responses that go through the
different policies.
o Add Headers Operations
 Add Request Headers
 Add Request Headers List
 Add Response Headers
 Add Response Headers List
o Remove Headers
o Set Response
o Set Request
● Caching in a Custom Policy for Mule 4: provides the cache for your custom policy, thus avoiding making external
calls multiple times. It is share with the Mule Application. Is only for CloudHub and hybrid applications. Can be used by
multiple policies applied in different APIs running in different instances in CloudHub.
● Authentication (Security Context): can be exposed through the Authentication object within the Security context
object, using the SDK Mule extension (Authentication Handler). It will be available to other policies and to the
application. Can be accessed using DataWeave
o #[authentication.principal]
o #[authentication.password]
o #[authentication.properties.someProperty]

All contents © MuleSoft, LLC
Thank you
www.mulesoft.com