Salesforce & Azure Web Services - Secure Tunnel Integration Patterns
Salesforce & Microsoft together are a common choice of vendors (Salesforce CRM, Office 365 & Azure) for many customers, although the integration options mostly rely on open standards and public internet connectivity between the two clouds.
This article examines how to establish a link between them via a secure tunnel.
Azure Web Services
You can build scalable internet facing web services on Azure, such as Azure Functions and Azure App Services. These can in turn access other Azure resources such as Azure SQL, Azure Cognitive Services and (soon) Azure ChatGPT. The service endpoints can be published on the public internet, or secured behind a private network.
Is TLS not enough?
A service hosted on Azure will be secured automatically by HTTPS and TLS protocols. This will encrypt all messages between Salesforce and Azure, and is how most web traffic works today. This is ‘good enough’ for most system communication over the internet however the security landscape is always changing and one day it will become either compromised or obsolete.
Additionally, other types of attack, such a Denial-of-service (DoS), can severely disrupt your business without even reading your traffic. An open endpoint on the public internet exposes you to that risk.
Therefore your company may have the requirement to pass system to system traffic through secure tunnels at all times, and this is the scenario this article is addressing.
It is not to say that HTTPS and TLS should never be used by itself to communicate sensitive data, however that needs to be a conversation you have with your security team.
VPN Tunnel Approach
One popular method to connect the two systems is via a ‘Virtual Private Network’ VPN tunnel and this article assumes that method. You should fully understand the benefits, capabilities and limitations of this approach, and check others as well, such as Megaport’s Virtual Router .
Salesforce Cloud Infrastructure Basics
Salesforce is hosted on either their own data centers, Alibaba in China, or (increasingly) on Amazon AWS. Azure is only available on Microsoft Azure data centers and therefore communication between the two clouds will have to cross the public internet in some form.
You cannot set up a direct VPN tunnel from the core Salesforce (Sales/Service) platform, therefore your first decision point will probably be whether your integration can pass through the public internet, or require further networking infrastructure for security, speed and reliability.
Option 1: Salesforce to Azure over Public Internet (no VPN Tunnel)
Calling out to Azure over the public internet is actually fine under many scenarios. You need to analyse and decide this as an organization and have executive sign-off on the decision.
It really doesn’t need saying, but never hard code your credentials in Apex. Use Named Credentials or other best practice within Salesforce.
For reliability you could use an APEX custom retry framework such as this Github project .
Option 2: Salesforce Express Connect to Azure (fast but not secure)
I mention this one only because it could be easily assumed it is a supported secure option, when in fact it it does not offer any (real) additional security at all.
Salesforce offers (through partners) Salesforce Express Connect that provides a dedicated channel that addresses both speed and reliability, but important to note that it does not offer additional security.
Also important to note that it currently does not work with Hyperforce or Salesforce Public Cloud. Alibaba does appear to support it.
Option 3: Salesforce + Mulesoft to Azure
Many Salesforce orgs do use MuleSoft Anypoint for integration and that can provide more robust and secure options. MuleSoft Anypoint is hosted on AWS, although do bear in mind that even in the same AWS region Salesforce and MuleSoft will sit in different tenants albeit secured via a Connected App.
Mulesoft and Azure can be easily configured to use a VPN between them.
The MuleSoft ‘Proxy App’ is actually a very simple App to build, does not require much in terms of licensed vCores, and will just receive the request from Salesforce and pass the payload onto Azure via the VPN connection.
Additionally it can provide configurable retry and network error handling logic that would have to otherwise be Apex coded in Salesforce. It does obviously require some MuleSoft skills to implement:
Positives: Easy to setup if you already have MuleSoft
Challenges: MuleSoft Skills needed to build
Option 4: Salesforce + Amazon AWS to Azure
This is admittedly a bit strange, however if you are invested in both AWS and Azure, then you could consider using Amazon AWS with the new Private Connect as a bridge. You can create a proxy AWS Lamda Function with AWS Site to Site VPN to turn call Azure:
The main issue is that most use cases for Azure can also be built on AWS, which means that there are very few scenarios where you would want to do this with Azure.
Positives: Architectural landscapes with existing AWS infrastructure. Established security patterns to connect AWS with Azure VPN’s
Challenges: Solution complexity, Duplication of services, Requires AWS skills
Option 5: Salesforce Functions to Azure
The core Salesforce platform does not support connecting to VPN tunnels, however you could leverage Salesforce Functions with the Node OpenVpn package to call out to the Azure VPN:
You could also build the Function in Java as well.
Positives: Simple for Salesforce Orgs already licensed with Functions. Solution simplicity with no seperate integration system.
Challenges: You need to add the VPN library and logic into your code rather than configure dedicated VPN infrastructure
Option 6: Salesforce + Heroku to Azure
This is similar to the Salesforce Functions approach, however requires more setup and configuration. Additionally you have to establish security between Salesforce and Heroku that doesn’t come out of the box as per Functions.
This might be an option if you already have Heroku, or if the licensing is significantly more advantageous than Salesforce Functions. You also have the choice of a wide range of languages for the Web Role:
Positives: Architectural landscapes with existing Heroku infrastructure
Challenges: Solution complexity, Duplication of services, Requires Heroku skills. You need to add the VPN library and logic into your code rather than configure dedicated VPN infrastructure
Conclusion
There is no one ideal option for integrating your Salesforce application directly to Azure hosted services. It will be an architectural choice that depends on your existing vendor licensing, CAPEX and OPEX budgets, platform skill sets and security requirements.
Note that both MuleSoft and AWS still require some coding for the proxy app. I just regarded it as preferable to have the VPN infrastructure as configurable rather than use a library in the proxy app to achieve the same result.
Additional Notes:
- All diagrams assume Salesforce in hosted on Amazon AWS since this is Hyperforce and the way of the future. As mentioned, Salesforce Public Cloud, Alibaba and maybe others are possible as well.
- On reflection, you could just replace Azure with Google Cloud and all the options above still largely apply.
- The total licensing cost between the options could be significant and certainly specific to your vendor landscape, agreements and geography. I haven’t tried to compare that aspect at all
- You are already working with Salesforce and Azure, and it can be hard to find people who can also code and configure the other platforms in the options. This could also significantly add cost.
- Also consider the volume and type of service calls coming from Salesforce. There are callout limits and more general platform limits on the Salesforce side to consider.
- The AWS option requires a lot more detail, such as setting up a Virtual Private Cloud and VPN configuration.
- The AWS option is also not limited to VPN tunnels. There are alternative ways to achieve AWS to Azure such as a third party Virtual Router.
