API Group in Anypoint Platform

In this article, understand API Groups using a real-world analogy of our DZone. :)

What Is API Group?

At DZone, we have Integration, Cloud, MicroServices, etc. as separate zones. Each zone has articles/refcards/guides for the same technical goal of understanding that specific technology better.

Mule4 Automated Policy

Types of Mulesoft Policy


Support for Automated Policies

  • Automated policies are only available for Mule runtime engine (Mule4) APIs using a MuleSoft-hosted control plane.
  • All runtime deployment targets support automated policies (CloudHub, Runtime Fabric, and Hybrid).
  • Automated policies have priority over the same types of policies already applied to a specific API proxy.
  • As an administrator, we can apply policies specific to external identity providers (IdPs, such as OpenID) if the environment to which you want to apply policies includes them.

Steps to Apply Automated Policy

  • In the API Manager, select Automated Policies from the navigation menu on the left.
  • Click Apply new automated policy.
  • Select the provided policy that you want to configure.
  • Apply to a specific set of runtimes.
  • Click Apply.

Select Exchange Policy screenshot

Building HTTPS Proxy With Anypoint API Manager and MuleSoft

Anypoint API Manager has capabilities of enabling the HTTPS proxy by using secrets stored in the Secret Group to build the HTTPS enabled APIs for Cloudhub and Hybrid implementation.

Secret Manager is basically used to store the secret like Keystore, Truststore and configure the TLS context, which can be used with Runtime Fabric and API Manager in Cloudhub.

Step-by-Step Guide on How to Apply Client ID Enforcement Policy in Mule 4

In this step-by-step guide, we are demonstrating exact steps of how Client ID Enforcement Policy can be applied in Mule4 using Autodiscovery and API Manager.

Prerequisites

  • Must know how to write RAML and publishing it to Exchange
  • Must be familiar with Anypoint Studio
  • Must be familiar with Anypoint Platform

There are five parts in this tutorial. After completing all of these parts, we will end up having a Client ID Enforcement Policy implemented on the API.

Custom Policy in Mule 4

Custom Policy in Mule 4

Mule provides a set of policies beforehand, but there might be a requirement that is not covered by predefined policies. In such cases, a custom policy can be developed. The process is a three-step workflow:

  • Developing the policy
  • Deploying/Uploading the policy to exchange
  • Applying the policy on API
You might also like:  Working With Custom Policy in Mule 4

Setting up and Creating the Project

Before diving into the development, setup Maven to create the required project structure.
In settings.xml , under the  profiles section, add the below profile:
<profile>
<id>archetype-repository</id>
<repositories>
<repository>
<id>archetype</id>
<name>MuleRepository</name>
<url>https://repository-master.mulesoft.org/nexus/content/repositories/public</url>
<releases>
<enabled>true</enabled>
<checksumPolicy>fail</checksumPolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<checksumPolicy>warn</checksumPolicy>
</snapshots>
</repository>
</repositories>
</profile>