Securing IBM WebSphere Cast Iron Appliance while integrating with Salesforce-Part II


This article is the second in the five part series on securing IBM Websphere Cast Iron appliance while integrating with Salesforce.  In part-I we discussed about the security challenges an organization faces when integrating on-premise applications with Salesforce. We also listed out four different solutions to address those security concerns. In this article, we will cover the first solution which is Firewall Access Restriction.

Firewall Access Restriction

The first line of defense for any organization’s network is the very common solution: ‘The Great Firewall’. Defining firewall policies is a de facto method for every organization to secure their servers and systems from the external network / internet. A set of firewall policies can be defined to accept incoming requests only from servers or other trusted servers. This prevents any malicious user to access the enterprise’s servers illegally. This may sound odd, but it could happen if the organizations doesn’t have proper security mechanisms in place to secure the access credentials or somehow the access credentials got hacked. What if a disgruntled employee has access to these credentials and wants to bring down the system and illegal requests from different network? Securing the Cast Iron server by allowing incoming requests only from trusted IP address ranges/domains will make sure that these kind of illegal requests will be kept at the bay.

Though, firewall policies can protect unauthorized access requests, there are some interesting things that needs to be looked into carefully.

  • Typically, the outbound requests from Salesforce to your Cast Iron Server can originate through one of the following methods:
    • Outbound SOAP messages invoked by either workflow rule or approval process.
    • Custom Apex code that makes a callout to external web service
    • AppExchange app that you configure to make a callout to external web service

          In all the above methods, the developer has the capability to configure or code the target, but can’t define the source IP address/domain name. And guess what – when a request is made to the external web service (i.e., to your IBM Websphere Cast Iron Server), the request will not have the origination address as ‘’ or other related domain names (such as, etc…). The way the Salesforce works is as follows: Salesforce has a pool of IP addresses which is mapped to their servers in their cloud. When the client (an outbound SOAP message or custom apex code or appexchange app) makes a callout to the external web service/REST service, the request may originate from any one of these IP addresses – this is how Salesforce load balances the outgoing requests. So an outgoing request will always have one of these IP address as the origination address instead of the or any associated domain names. Hence the network admin has to use these IP addresses to configure in your firewall instead of the domain names. The list of IP addresses can be obtained from your Salesforce account representative.

Note: The IP address range will differ based on the domain that your org is located. For e.g. if your domain is on one of the na servers (North America), then you may get around 4 IP address ranges each having 25 IP addresses.

  • Having said that the requests carry IP addresses from a  common pool of IP addresses, we have couple more interesting problems to solve:
    • Since every Salesforce customer has their orgs run on the same Salesforce cloud, the outbound requests of the web services of all these companies may originate from the same IP address range, at least from the organizations that are co-located as yours. How would you make sure that the request that your Cast Iron server receives comes only from the org that your company owns? Theoretically, it’s very well possible that either accidentally or maliciously a user may point incorrectly to your org’s server, though in practice that’s almost impossible. Irrespective of that, from security standpoint, we cannot afford having a loophole in our network to be exploited.
    • The next challenge is that, even if the request comes from your company’s org, it might pose an additional problem. Typically every company will have at least couple of orgs, one for production and another set for non-production, such as DEV, QA, UAT, etc. Similarly, they might have different environments (DEV/QA/UAT/Prod [as depicted in part-I] ) for Cast Iron servers in the DMZ, targeting the corresponding environments within the enterprise network. How would you make sure the request comes from the appropriate org (DEV/QA/UAT/Prod) that targets the appropriate environment? This is a very common problem most enterprises experience, specifically, small to medium companies, where either there is proper process or no dedicated administrator in place to manage. I say that it is very common, because, unlike the internal network, where the network boundaries are clearly defined and a firewall policy is set to prevent cross environment access. This is not possible with Salesforce, because as I explained previously, from whichever org the request originates (i.e. production or non-production), it is not possible to classify the org based on the IP address, because Salesforce doesn’t provide that detail. For e.g. let’s say you have a custom configuration ‘DMZCIURL’ which you use for referencing your DMZ Cast Iron server and suppose you have the value as ‘’. When you refresh your DEV sandbox from production, the value for the custom setting is carried over to the DEV sandbox by default. If this custom setting is not updated to point to the DEV Cast Iron and if a developer runs the workflow rule / custom apex code that makes a web service callout, the request is going to hit your production Cast Iron server and not your DEV Cast Iron server. boooom….

Though it seems a big problem, fortunately we do have solutions to prevent these kind of situations. We will answer all these questions in the subsequent articles.

As previously described, the firewall, specifically the external firewall,  will act as the first line of defense. The following rules can determine which IP addresses/hosts to be added to the firewall.

  • The IP address range obtained from Salesforce
  • The domain name/IP address from any other cloud service provide that you integrate with your on-premise applications (for e.g. DocuSign, Concur, etc.
  • The domain name/IP address of the digital certificate signer (such as verisign, digicert, etc.) [This can be removed from the firewall policy after the initial setup, you need it at the initial stages to troubleshoot any issues when you setup the SSL certificates]

Once the rules are specified and deployed, now the incoming requests will be allowed only from the trusted IP addresses/domain names.


This article covered the topic of securing the enterprise network using firewall at a high level. We also discussed about the additional challenges that we need to solve. The part-III of this article series will answer some of the questions raised in Part-I.


Tagged: , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: