Mulesoft Dedicated Load Balancer Use Case
An analysis of a recent use case implementing dedicated load balancers, and the drawbacks in authentication and certificate sharing.
Join the DZone community and get the full member experience.Join For Free
We have recently implemented dedicated load balancers (DLB) into our integration landscape. I am sharing details about our use case.
Before having DLB, the VPC received all the traffic through the shared load balancer (SLB) or directly to mule internal workers through VPN. There were two limitations to this approach:
We were unable to enforce mutual authentication for the endpoints exposed. This was essential for the SOAP-based endpoints as we do not have a client Id policy enabled in this case.
Secondly, for HTTPS applications, we returned CloudHub's certificate and not the organization's certificate to the consumers.
DLB Use Case
Let’s have a look at how DLB is placed right now or, at least, how we have envisioned it currently. In the figure depicted below, I have mentioned one consumer of each type. The first type, the one going through SLB (shared load balancer), are not required to have mutual authentication whilst the other type, through DLB, need transport layer security.
To note: Internal Consumer type is accessing, through the VPN, the link
http://mule-worker-internal-<applicationName>.eu.cloudhub.io. This is also planned to be accessed through DLB later.
For SLB we use
https://<appName>.eu.cloudhub.io/api/<resource> to access applications and for DLB, we use
Delving more into DLB, as depicted in the figure above: DLB is between Consumer and VPC. The connection between Consumer and DLB is over HTTPS (mutual authentication), whilst the interaction between DLB and VPC is over HTTP.
Assume a case where we have one application to expose to the consumers (with mutual authentication enforced). In this case, for each client, we will need one certificate pair. Now obviously that is not a feasible scenario to have different certificate pairs for each consumer. This approach is neither cost-effective nor is good to have from the maintainability perspective.
In our case, the Integration platform enables mutual authentication by exposing a single endpoint to all the consumers. We handle this at the application level, where we determine if the client is authenticated or not. In case the client is not Authenticated, necessary actions are taken in the code (such as limit access). DLB passes the information about client authentication in the header
x-ssl-client-verify. The value of this header is evaluated in the code to make a decision.
Opinions expressed by DZone contributors are their own.