DEV Community: Takahiro Yamamoto

mTLS in CloudHub 2.0 : What Developers Need to Know

Takahiro Yamamoto — Mon, 28 Aug 2023 11:21:55 +0000

Understanding mTLS

Before diving into the specifics of CloudHub, let's briefly touch on mTLS. mTLS is a two-way authentication process between the client and server. While traditional SSL/TLS ensures server-side security, mTLS ensures that both the client and server authenticate each other.
To harness mTLS in CloudHub, developers must ensure that every API consumer is mTLS compatible. But, as in any real-world scenario, there might be a mix of consumers - some capable of mTLS and some not.

mTLS in CloudHub 1.0

In CloudHub 1.0, by setting the Dedicated Load Balancer (DLB) 'Client Certificate Validation' to 'Optional,' API access was granted even to those consumers that couldn't handle mTLS. Developers could then inspect the 'X-SSL-Client-Verify' header in their APIs to ascertain whether a valid client certificate was transmitted.

mTLS in CloudHub 2.0

The landscape has shifted a bit in CloudHub 2.0. Unlike its predecessor, CloudHub 2.0 doesn't offer the flexibility to optionally set mTLS. Instead, developers need to prepare two distinct endpoints - one with mTLS enabled and one without. The crucial decision lies in the application's Ingress settings, where developers specify which endpoint to use based on whether mTLS is required or not.

Conclusion

Adapting to CloudHub 2.0's mTLS implementation requires some rethinking and retooling, especially for those who have been operating with mixed API consumer environments in CloudHub 1.0. By understanding the core changes and preparing adequately, developers can continue to ensure secure and seamless integrations in the MuleSoft ecosystem.

How to Set HTTP Error Responses in MUnit Testing

Takahiro Yamamoto — Mon, 10 Jul 2023 11:18:08 +0000

The development of efficient and robust MuleSoft applications requires comprehensive unit testing, and MUnit is an invaluable tool for this purpose. In this blog post, we'll delve into some tips for handling error status returned from the 'HTTP Request' backend during unit testing.

When we have logic that branches based on the contents of the response, the unit testing approach becomes a bit more intricate. The response body of the error status returned from the backend is stored in 'error.errorMessage.payload'. In typical situations, you might want to directly assign a value to this field using 'Mock when'. However, 'Mock when' doesn't allow you to set a value to 'error.errorMessage.payload'.

So, how do we work around this limitation? Here comes the 'Then Call' to the rescue. In the subflow called by 'Then Call', you can use the 'Set Event' to establish an exception. This way, you're able to mimic the desired behavior by setting the 'error.errorMessage.payload' as part of the flow.

The type of exception you're looking to set here should be an instance of the 'ResponseValidatorTypedException' class from Java. It accurately represents the sort of exception that would occur in a live environment when an error status is returned from the backend.

%dw 2.0
output application/java

var detailMessage = 'Internal server error'
var errorType = java!org::mule::extension::http::api::error::HttpError::INTERNAL_SERVER_ERROR
---
java!org::mule::extension::http::api::request::validator::ResponseValidatorTypedException::new(detailMessage, errorType, message)

By leveraging this technique, you can achieve a more accurate and efficient unit testing process for your MuleSoft applications. It allows you to replicate the behavior of the 'HTTP Request' backend error status more accurately in your tests, ensuring that your code is capable of handling such scenarios in real-world operations.

Remember, comprehensive unit testing is a crucial aspect of creating reliable and robust MuleSoft applications. Therefore, understanding how to handle and mimic different error statuses during testing can significantly enhance your application's quality and reliability.

In conclusion, unit testing with MUnit in MuleSoft Applications might appear challenging, but with the right approach and understanding, it can be manageable and effective. Hopefully, this post has offered you some useful insights into this topic. Happy testing!

Leverage Exchange Mocking Service with Mocking Service Proxy

Takahiro Yamamoto — Mon, 22 May 2023 10:54:26 +0000

Introduction

Anypoint Exchange's Mocking Service is a powerful tool that provides real-time feedback during the API design process.
This article discusses the ways to use the Mocking Service, its drawbacks, and the proposal of the Mocking Service Proxy as a solution to these challenges.

Accessing the Mocking Service

Access to the Mocking Service from application essentially comes in two forms - public and private.

Public

The Mocking Service for assets published in Public Portals can be called without authentication.
However, the downside of this approach is the potential exposure of the API specification to external parties.
Therefore, this option needs careful consideration when security is critical.

Private

On the other hand, In the case of not publishing to Public Portals, access to the Mocking Service is limited to a specific set of users or groups.
However, this method requires implementing an additional program to obtain an access token from the Anypoint Platform.

Proposal of Mocking Service Proxy

As a solution to these issues, we propose the creation of a Mocking Service Proxy.
This Proxy encapsulates the process of obtaining the access token and allows usage with regular API authentication methods such as Client ID and Client Secret.

A major benefit of this approach is the ability to utilize the Mocking Service without exposing the API specifications and eliminating the manual process of obtaining the access token.
This allows developers to focus on make an application that call the API.

Mechanism of Mocking Service Proxy

The Mocking Service Proxy is based on the Endpoint with Proxy Mule application, which is generated through the API Manager.
The standard operation of the Endpoint with Proxy Mule application is to route the incoming API calls to the appropriate endpoints.

Before routing the API calls, the Mocking Service Proxy executes a process to obtain an access token from the Anypoint Platform.
This process encapsulates the client authentication method - using Connected App - and uses this information to request an access token from Anypoint Platform's authorization server.

Once the access token is obtained, it is attached to the API call as a token in the MS2-Authorization header.
Following this, the API call is routed to the appropriate endpoint, just as in the normal operation of the Endpoint with Proxy Mule application.

Now comes the decision-making process for routing. The Mocking Service Proxy determines which Mocking Service asset to call based on the first path segment. For instance, if the API request is /asset1/data, the Mocking Service for asset1 will be called.
This design allows efficient routing and ensures that the appropriate Mocking Service is called for each request.

Other approaches can also be considered for determining the Mocking Service to be used, such as determining based on HTTP header or setting up a Proxy for each asset. However, the first path segment-based approach provides a simple and effective solution that balances flexibility and complexity.

Benefit

One significant advantage of using the Mocking Service Proxy is its ability to bridge the gap between calling a Mocking Service and a implemented API endpoint.

For example, a implemented API endpoint require authentication using a Client ID and Client Secret.
On the other hand, a Exchange Mocking Service not require these authentication steps or has dedicated authentication steps.

The Mocking Service Proxy addresses this issue by encapsulating the authentication of Exchange Mocking Service process within its workflow. Requiring no additional steps from the developers.

In this way, the Mocking Service Proxy enables a seamless transition between the development and production environments. It allows developers to focus on the core aspects of their work - designing and implementing the API - without worrying about the intricacies of the authentication process and environmental discrepancies.

Sample Implementation

I have created a sample implementation that can be used as a reference.
You can find the sample implementation here. Please note that you may need to adjust the implementation to suit the specific needs and requirements of your project.

Conclusion

While the Mocking Service is an excellent tool for rapid feedback during the API design phase, its usage comes with certain challenges.
By leveraging the Mocking Service Proxy, these challenges can be addressed, making the development process more efficient.

The Mocking Service Proxy encapsulates the process of obtaining access tokens.
This allows developers to focus on application that call the API development.

Custom Alerts and Notifications in CloudHub 2.0

Takahiro Yamamoto — Tue, 22 Nov 2022 10:37:46 +0000

In the case of using CloudHub 1.0, Custom alerts and notifications are often used in the Non-API application (i.g. Scheduler, MQ listener) for error notification.

Unfortunately, CloudHub 2.0 does not support custom notifications for now.
CloudHub 2.0 for CloudHub 1.0 Users | MuleSoft Documentation

We need to consider alternatives, in using CloudHub 2.0.
Sending an email directly using an Email connector and Amazon SES may be one workaround, but it depends on external service.
And I’d rather not change the architecture from the current.

I believe to be supported some notification function in CloudHub 2.0 near future.
I came up with an interim measure until that is implemented.

It's so simple, using custom notifications on CloudHub 1.0 in CloudHub 2.0.

Create empty application and deploy it to CloudHub 1.0, it called 'customer-papi-alert', and stop it. (save vCores)

And set the alerts on 'customer-papi-alert'.

Create real application and deploy it to CloudHub 2.0, it called 'customer-papi'.
The domain field of 'Create Notification' is 'customer-papi-alert'.

The illustrate for behavior.

That's it.