This article is the fifth and final part of the article series titled ‘Securing IBM Websphere Cast Iron while integrating with Salesforce. In this article, we will uncover the final piece of the puzzle: authenticating the incoming requests using web services.
Authenticating the user requests
Since IBM Websphere Cast Iron server is in DMZ, it is exposed to the public internet which enables to be accessed from any device. We saw couple of techniques to safeguard the access to the server at various levels from firewall to transport layer in the previous articles. At the application level, the IBM Websphere Cast Iron doesn’t provide out of the box security such as ‘Authentication’ or ‘Authorization’. To overcome this limitation, this article proposes a technique – using external web service to authenticate the client requests. ‘Authentication’ provides the ability for the web service host to challenge the client to provide access credentials, typically user name/password, but not limited to, to enable the access to provide integration capabilities. Authentication process generally involves in using the standard authentication mechanisms such as Windows Authentication, Kerberos or Forms based authentication. Covering the details of these authentication mechanisms is out of scope of this article. Hence this article will focus on providing a simple way to authenticate the client requests using standard web services technology.
As previously said, the IBM Websphere Cast Iron server doesn’t provide any type of authentication or authorization capabilities out of the box. So, a simple technique to overcome this limitation would be to implement the authentication and authorization services in an external stack such as J2EE or Microsoft .NET as standard web services and utilize these web services to provide the authentication/authorization capabilities. These web services in turn can implement any type of authentication mechanism from Windows to Kerberos to Forms based; using either user name/password credentials or a security token based credentials or simply oAuth based authentication.
This article will implement a simple web service based on .NET WCF web services technology to provide the authentication service. The Cast Iron orchestration can utilize this web service to authenticate the incoming requests and route the call or perform further integration logic or simple reject the call based on the result from this web service. The following diagram captures this flow:
Cast Iron Orchestration – This Cast Iron orchestration is an example for calling an authentication web service hosted in external system. The code for the Cast Iron orchestration can be downloaded from here. The following image is extracted from the Websphere Cast Iron Studio that demonstrates the flow of the orchestration.
Authentication Web Service – The authentication web service is a simple .NET WCF web service that takes the security credentials as an XML dataset and returns the authentication status.
Since the article’s purpose is to demonstrate the technique, this web service doesn’t implement any particular authentication mechanism. But as the reader can observe, it is fairly easy to implement any type of authentication mechanism within this web service. The code for the .NET WCF web service can be downloaded from here.
This article series exposed the security challenges in integrating Salesforce with on-premise applications in the context of IBM Websphere Cast Iron as the integration platform. It also explored various techniques from firewall rules to transport level authentication to custom validation service to external authentication service to address these challenges. Neither the security challenges nor the solutions are complete, but it gives an idea about the security concerning the cloud to on-premise integration and various solutions to address them. The techniques explained here can be implemented with any integration platform and not limited to IBM Websphere Cast Iron, though the implementation details will differ.