In my daily interactions with MuleSoft customers, I always get the question what I regard as the most effective way to secure Mule applications and APIs on Anypoint Platform. A majority of our customers deploy their Mule applications on CloudHub — our MuleSoft managed and hosted cloud offering. So by the default, any application that gets deployed on CloudHub is exposed to the outside world and needs to be secured — from an access and authentication perspective, as well as a Quality of Service and compliance perspective. That is even more critical when a company documents their APIs in a portal such as Community Manager with the goal of sharing business functions.
So what are the different options to secure your APIs using capabilities on Anypoint Platform and existing framework and services? In this short blog post, I will outline three common options with their pros and cons, so our customers can make an informed decision.
1. Custom code using existing frameworks
Mule apps are written in Anypoint Studio — an Eclipse based IDE — using visual tooling and drag-and-drop functionality. Under the covers, the Mule apps are running as Java applications on a Java runtime with their configuration stored in XML files. This means that developers can use existing Java frameworks and functions (such as Spring) to secure their apps by importing respective libraries.
For example, a developer could implement a library that authenticates requests against a Mule application with an exposed API using the Spring Security Authentication framework and implement OAuth 2.0 / OpenID Connect capabilities using an OAuth provider, such as Okta. Other security related functions (such as whitelisting / blacklisting, tokenization / de-tokenization) could be implemented this way as well.
The upside of this approach is that developers could write custom functions that fit the security requirements 100%. However, the major challenge with the custom code approach is that these libraries will have to be embedded into all deployed Mule application that need them (probably all of them). So once security requirements or endpoints change over time, the security libraries will have to be maintained and updated — and all of the Mule applications will likely have to be redeployed as well which could result in a disruption to the business over time.
2. External third party or cloud services
Some customers are heavily invested in cloud platforms such as AWS, Google Cloud, and Microsoft Azure. Many are considering using capabilities from these cloud platforms to secure their Mule endpoints using a “best-of-breed” approach.
As an example, a customer could use the Amazon API Gateway or Google Cloud Identity to control access to a Mule application running on Cloud Hub. In the Quality of Service area, many cloud providers also offer solutions to control rate limits and enforce spike controls that can theoretically be used to further secure Mule apps.
While this approach gives companies flexibility to pick the best tools for the job, it also has a major drawback: a lot of thinking has to go into end-to-end security since the actual Mule endpoints are still exposed on CloudHub. The IT teams will have to create a Virtual Private Cloud and utilize web firewalls and tunnels to effectively secure the end-to-end traffic that passes between the capabilities on the cloud platforms and Anypoint Platform.
The challenge is that this approach — though it may potentially be cost effective – creates technical debt that will be hard to untangle later, and that will further complicate the task of quickly creating business functions and exposing them as APIs. Also, companies create a dependency on third party solutions that may change over time — or even worse, may not be available suddenly which would unnecessarily expose the APIs.
3. Anypoint API Manager
The third option is to use an out-of-the-box component within MuleSoft’s Anypoint Platform — the API Manager.
It basically creates an API Proxy for each backend API running on Anypoint Platform and thereby secures requests coming into the platform again the API.
All of the proxies run on the out-of-the-box API Gateway that services as the point of enforcement for API policies.
Developers can now quickly attach API policies to the endpoints and secure them efficiently without changing the underlying code being dependent on external solutions.
The following table gives an overview of the out-of-the-box policies that can be used against any Mule app running on Anypoint, and soon even against containerised non-Mule apps that are registered with our new upcoming Anypoint Service Mesh product.
What makes Anypoint API Manager a compelling solution — compared to the other approaches — is that its components are tightly integrated with Anypoint Platform, so will not require additional thinking about firewalls or tunnels. The policies can also be easily applied or removed from APIs with no custom coding and no redeployments involved.
Regardless of whether an organization intends to use APIs internally or externally, applying policies through API Manager will ensure a high degree of security and performance.
To learn more about API Manager, check out our product page.
