Securing Mobile Web Application access with OCI Load Balancer and Transport Layer Security (TLS)

Oracle Mobile Supply Chain Application Apps (MSCA) / Mobile Web Applications (MWA) rely on a telnet-style protocol to connect from the client - be it an Android or iOS device or be it a dedicated scanning hardware - to the application server.

Oracle MSCA/MWA architecture, see https://docs.oracle.com/cd/E26401_01/doc.122/e48826/T256582T257759.htm

I've seen many customers that rely on unencrypted traffic from the mobile devices to the telnet server running as part of Oracle E-Business Suite 12.2. Nowadays, this is no longer state-of-the-art as well as a severe security risk. Fortunately, for quite some time now, MWA/MSCA can be run in a way to run through an encrypted TLS tunnel. This is documented in 2108155.1.

Unfortunately, the process to set this up as described in the note is not trivial, especially since it means there is another place where SSL certificate/keys need to be maintained. Furthermore, with this approach, it is no longer possible to use the MWA dispatcher to dispatch between multiple telnet servers (2175344.1).

For a recent project, we thus decided to terminate TLS at a load balancer on OCI instead of at the MWA application server itself. That gives us encrypted connections through (potentially) less secure networks from the mobile device to the OCI Load Balancer - e.g. even using let's encrypt certifcates as described here: Oracle OCI Load Balancer with Lets Encrypt (free) SSL certificates. And on the E-Business Suite side, it requires no additional setup compared to a non-encrypted setup. Let's see how we managed to achieve this.

First of all, you need to setup MWA/MSCA the usual way (and without TLS). Besides applying the required / recommended patches for the latest mobile application clients, for this, edit the $CONTEXT_FILE and set the parameters for s_mwastatus as well as for s_other_service_group_status to "enabled". After running adautocfg.sh and bouncing the environment, the MWA dispatcher should be running on port 10800. This can be verified with a quick test on the server itself by connecting through a telnet tool to localhost:10800.

Then, create a backend set on an appropriate load balancer as follows:

sudo firewall-cmd --zone=public --add-rich-rule 'rule family=ipv4 source address=172.31.10.0/24 port port=10800 protocol=tcp accept' --permanent

sudo firewall-cmd --zone=public --add-rich-rule 'rule family=ipv4 source address=172.31.10.0/24 port port=10800 protocol=tcp accept'

On the OCI side, network connectivity between the load balancer network and the E-Business Suite Application server (port 10800) needs to be enabled for the relevant security list. Then create a backendset as follows on an appropriate load balancer:

OCI Load Balancer Backendset with health check

It is only possible to setup a TCP level healthcheck. Furthermore, typically you just have a single backend which points to the MWA dispatcher.

As the last setup, enable TLS for the Load Balancer by creating a listener as can be seen in the following screenshot:

OCI Load Balancer Listener providing a TLS encrypted endpoint

Keep in mind that Server Name Indication (SNI) does not work in such a scenario, since there is no HTTP but just plain telnet sent through the tunnel. Therefore you'll need to use different ports if you have multiple E-Business Suite environments behind a single Load Balancer.

After having completed the above steps, add hmyhostname:10861 to the MSCA app from the Android Play store; the connection can be established and is now fully encrypted from the mobile device to the OCI Load Balancer:

MSCA App connecing with SSL to the OCI Load Balancer

The above approach allows to setup a TLS encrypted access to MWA/MSCA servers conveniently. For many of our customers, there is already an OCI Load Balancer in place that has the correct SSL Certificates to terminate the usual HTTP(S) traffic. Adding termination of an encrypted MWA/MSCA port is then very easy and does not incur any additional costs or a lot of effort.