What is the problem?

The problem is fundamentally, that a lot of Oracle customers are still running the Oracle E-Business Suite 11i and without the support of the vendor are opening themselves to potential issues. The first issue is that they loose the ESB services for incompatibility between the desktop client and the ESB server. Because the desktop client changes over time (Windows patches, browser updates and Java updates) the ESB server would normally change as well. At the end of support the ESB servers will remain static and will therefore not follow the changes on the desktop client anymore.

The other issue follows the logical reaction to the first one. If the ESB servers are static, so let's make the desktop clients static as well. Stopping the windows, browser and Java updates on the desktop would solve the issue. The ESB would continue to work. But over time the desktop would become full of potential security vulnerabilities. Most of the desktop updates issued today are patches of bugs, which have a publicized exploit vulnerability.

What is the risk?

The main business risk is:
• potential loss of ESB functionality
• increased desktop security vulnerability

The business impact needs to be assessed individually, but as time goes on the probability of loosing the ESB functionality or having the desktop attacked increases. At the same time any migration or upgrade of an ESB system is a complex undertaking and will require some time.

How to mitigate the risk?

The official Oracle ESB blog suggests: "You may need to freeze your desktop and server configurations while you upgrade...".

That is a very good advice, but unfortunately is not sustainable in any bigger organization for any longer period of time.

There are two necessary steps:
• freeze the ESB desktop client
• allow access only to the frozen ESB desktop client

This means the isolation of the ESB desktop client and enforce its use for only the ESB service access. And at the same time restricting the ESB service access only to the isolated desktop clients.

How to isolate the ESB desktop client?

The ESB desktop client is a web browser with a Java plugin for launching Java applets. In order to freeze it we will need the following functionality:

• the browser version doesn't ever update/upgrade
• the java version doesn't ever update/upgrade
• the browser can't be used for any other web sites then ESB services
• the browser identification string (user-agent) is unique

The recommended browser to modify is the Firefox browser. The Internet Explorer is not at all suitable, because of its tight links to the Windows OS. The Firefox can be deployed in a separate directory and this deployment can be individually customized. Changing it to a kiosk mode, where the URL is set and can't be modified is the first step. Customizing the user-agent string can be done through editing the about:config preferences. Stopping Firefox from getting automatic updates is well published. The java version deployed for this particular instance of Firefox can then be configured to stop checking for java updates as well.

How to enforce ESB service is accessed only by the frozen ESB desktop client?

The standard desktop client accessing ESB service could potentially hit an incompatibility and the end user would have limited or no functionality. This should be avoided and any user accessing the ESB service with browser other then the frozen ESB special should be redirected to an error page.

The best way to achieve it is by deploying a servlet filter onto the ESB servers, which checks the incoming requests for the User-Agent string. Only the user agents (browsers) identifying themselves with the string previously set in the frozen ESB client would be allowed to continue to the ESB services. Less intrusive option could be the deployment of a reverse proxy providing same functionality or even moving the ESB services to a different (unknown) location.

Do you agree or did you try it already? Please get in touch.