A Deploying Administrative Clients for Oracle Fusion Applications

In typical Oracle Fusion Applications deployment there are a number of administrative clients, or thick clients, from which end users (functional administrators) must have direct access to application servers or file systems via Hypertext Transfer Protocol (HTTP) or socket connections.

Some administrative-client applications are the following:

• FR (Financial Reporting) Studio

• Oracle BI Enterprise Edition Administrative client

• Oracle Business Intelligence Catalog Manager

• Oracle WebCenter Content: Imaging document-provider clients, such as

  • Oracle Forms Recognition (OFR Verifier, OFR Designer)

  • Oracle Document Capture

  • Mail Server for Oracle Document Capture

  • Inbound fax tools

• File Transfer Protocol (FTP) Server (and the ability for the end user to upload files)

• Oracle JDeveloper

• ODI (Oracle Data Integrator) Studio

Thick clients are usually installed on Windows servers, which sometimes sit unattended on end users' desktops at a customer location. Such open connections to sensitive data (such as that housed in a data center) are highly vulnerable to security breaches, and security best practices generally do not allow this kind of configuration.

This chapter describes how to address these security loopholes.

A.1 Recommended Solution

In order to close potential security loopholes, all administrative thick clients should be installed on host Windows servers that have secured HTTP remote desktop connections (RDCs). These servers should be located in each data center.

A separate administrative subnet, acting like an administrative demilitarized zone (DMZ) for thick clients, should be created in each data center to host the Windows servers.

End users (customers) will access the thick clients by logging in to the Windows servers through a virtual private network (VPN), and either a secured HTTP RDC or socket connection. Only the thick clients on the Windows servers in the administrative subnet will have access to application servers or file systems in a data center.

Note:

Since some client components, such as Oracle WebCenter Content: Imaging and FTP, are only integrated with socket connections, enforcing VPN access is required.

Figure A-1 shows the overall topology of the administrative subnet and its client components. Figure A-2 shows the topology details.

Figure A-1 Administrative Subnet Topology

Figure A-2 Administrative Subnet Topology Details

A.2 Implementation

Implementing the administrative subnet requires the following:

• An RDC service enabled over HTTP and wired with a load-balancing router (LBR) virtual IP (VIP) running over HTTP Secure (HTTPS).

  • The LBR VIP should only be internal facing and use Secure Network Address Translation (SNAT) to enforce tighter security.

  • VPN must be used for clients that require socket connections.

• Different file systems created/mounted on the Windows server(s) using a universal naming convention (UNC) path and running the Oracle Forms Recognition and Oracle Document Capture clients.

  • An x:\ directory, for example, where the Oracle WebCenter Content: Imaging Linux input directory will be exposed over a Common Internet File System (CIFS) to the Windows server where Oracle Forms Recognition is running. (Oracle WebCenter Content: Imaging needs read/write access to this file system; Oracle Forms Recognition needs only write access.)

  • A y:\ directory, for example, where Oracle Forms Recognition will write into the Oracle WebCenter Content: Imaging input x:\ directory. This is also the file system where Oracle Document Capture will write files to the import directory and Oracle Forms Recognition Runtime Server will read them on the Windows server. (Oracle Document Capture needs only write access to this file system; Oracle Forms Recognition needs read/write access.)

  • An Oracle Forms Recognition batch directory, which needs to be exposed so that end users can correct data recognition problems using the OFR Verifier. This file system also needs to be exposed to OFR Designer.

    • Because only a limited number of end users need OFR Verifier, it can be exposed through the remote desktop service (RDS).

    • This file system is similar to the y:\ file system topology.

  • An Oracle Forms Recognition project directory, which needs to be exposed so that end users can modify Oracle Forms Recognition project configurations using OFR Designer.

    • Because only a limited number of end users need OFR Designer, it can be exposed through the remote desktop service (RDS).

    • This file system is similar to the y:\ file system topology.

Certain accounts payable and accounts receivable situations have the following implementation requirements:

• A non-SSL Oracle Document Capture email server hosted in the administrative subnet to support the Oracle Fusion Expenses Oracle Document Capture email provider. Users in a customer network sends receipts through email attachments, the Oracle Document Capture email client processes the email attachments and drop them into the Oracle WebCenter Content: Imaging input directory.

• The installation of a client-specific Oracle Document Capture at the customer location that will be integrated with their local scanners. There are two methods used to import scanned documents into the Oracle Forms Recognition import directory:

  • Method 1: By FTP. When receipts are scanned, Oracle Document Capture writes them locally. An automatic process will FTP the scanned documents into the Oracle Forms Recognition import directory.

  • Method 2: By file sharing. When receipts are scanned, Oracle Document Capture writes the scanned files into a remote input directory within the data center administrative subnet that is exposed to the customer network over VPN.

  Oracle Forms Recognition reads and deletes the files and writes them into the Oracle WebCenter Content: Imaging input directory, where they are read and further processed.

  Method 1 is preferred because it does not expose the file system to the customer network.

• Access to a read-only Fusion database to allow Oracle Forms Recognition to query results.

Application administrators at a customer location must deploy applications from Oracle JDeveloper to an application server. This requires that the APPLICATIONS_BASE file system be mounted to the customer network. To implement the solution:

• Host Oracle JDeveloper on one of the Windows virtual machines within the administrative subnet. These Windows systems will access the client application administrators over the RDC with a VPN connection.

  Mount the APPLICATIONS_BASE file system to this Windows virtual machine.

• Using the FTP server running in the administrative subnet, FTP application artifacts to the subnet and then deploy them through Oracle JDeveloper.