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

Introduction

IBM Websphere Cast Iron can solve many integration problems without the traditional coding approach. This article series discusses about the security challenges when integrating on-premise applications with Salesforce. The first part of this article series introduced the security challenges and the second part continued with first of a set of solutions to secure the integration assets located at on-premise. In this article, we will discuss about adding security at the transport level.

TLS/SSL Authentication

Any information that goes in the public internet can be intercepted. Therefore, adequate security should be implemented at the transport level to ensure that the data is completely encrypted and unreadable from the prying eyes. The standard method to secure the transmission of data is by using the TLS/SSL authentication. Basically, in TLS/SSL authentication, the data is secured at the transport level by encrypting all the data that goes through the public internet.  The TLS/SSL authentication not only encrypts the data, but also provides the source and the target the ability to prove their identities. This is a great feature, specifically when integrating with the Salesforce. Recall the  security challenges that we discussed in part-I, where it was mentioned that the requests from Salesforce carry the IP addresses and not the Salesforce.com or other related domain names. Also, these IP addresses are shared by every other enterprises whose orgs are co-located in the same set of IP ranges. So, how does exactly the TLS/SSL solves the problem? The answer lies in the following sections.

One-way SSL/Certificate Authentication

In one-way SSL/Certificate authentication method, the provider secure the data transmission by implementing SSL/certificate based authentication. When a client makes a request to the server, the server proves its identity by providing the following information:

  • A digital certificate from the service provider with the provider’s information, such as Company name, address, phone, email, etc.
  • A digital certificate from the public Certification Authority (CA) such Verisgn, DigiCert, etc.
  • A chain of trust certificates if there are any intermediary CA’s.
  • An encrypted public key which the client can use to decrypt the data that the server uses to encrypt the data being transmitted

When the client receives this information, it verifies the provider’s digital certificate and upon successful verification, it establishes the secure communication with the server. With this method, the data is encrypted end-to-end throughout  the session. I have written a complete walkthrough on implementing one-way SSL/Certificate authentication here as part of five part article series on Making authenticated web service callouts from Salesforce to IBM Cast Iron Using SSL/Certificates. This solves the problem of the following questions:

  • Will the data be encrypted? If so, do we need to have the clients prove its identity?
  • What type of authentication do we need to use?

Two-way SSL Authentication

In two-way SSL authentication method, both the client and server proves their identities to have a secure communication. Once the mutual handshake is successful, a secure communication channel is established and the data transmission takes place on this channel where the data exchange is completely encrypted and can be decrypted only by the source and the target systems. A thorough walkthrough on the concept of two-way SSL/Certificate authentication with working example can be read in my previous article as part of the five part article series on Making authenticated web service callouts from Salesforce to IBM Cast Iron Using SSL/Certificates

This solves the following problems that we raised in the first article.

  • Will the data be encrypted? If so, do we need to have the clients prove its identity?
  • What type of authentication do we need to use?
  • What systems can access our Cast Iron server?
  • Who can be allowed to access our Cast Iron server?

The two-way SSL/Certification based authentication also solves another problem that we discussed in part-I, which is how to make sure if the request originated from our own orgs instead of some other enterprise’s org which is co-located with our org. Since, in two-way SSL/Certificate based authentication, both the parties need to prove their identities, if a request comes from somebody whose identity couldn’t be verified (using SSL/Certificates), then the server rejects the call.

Summary

This article discussed about using SSL/Certificate based authentication on securing the data communication between a server and client. In the next article, we will discuss about how to protect cross organization calls, so that even inadvertent mistakes of pointing to incorrect environments will be detected by the server and prevented from execution.

Advertisements

Tagged: , , , ,

One thought on “Securing IBM WebSphere Cast Iron Appliance while integrating with Salesforce-Part III

  1. Vikas September 16, 2015 at 8:11 am Reply

    Hi Hari,

    The article is nice.

    I am trying to configure two way SSL with Tomcat 6. I have tried my all the way but i am getting an error which has no solution for me. Please find the link for more details:

    http://salesforce.stackexchange.com/questions/92628/two-way-ssl-configuration-with-tomcat-6

    Any help would be appreciated.

    Thanks,
    Vikas
    guptavikaas27@gmail.com

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: