3 System Deployment

3.1 Network Security in an OHI Environment

When deploying OHI Applications onto a network there are many security issues to take into consideration, especially the use of firewall and VPN technologies. A firewall will permit or deny network permissions based on configured rules, to protect the internal network from unauthorized access while permitting legitimate communications. Firewalls perform the following functions in a typical OHI environment:

• Guard the company Intranet from unauthorized outside access.

• Separate Intranet users accessing the OHI system from internal subnetworks where critical corporate information and services reside.

• Protect from IP spoofing and routing threats.

• Prohibit unauthorized users from accessing protected networks and control access to restricted services.

Figure 3-1 Network security in an OHI environment

A typical OHI environment usually has the following security zones:

• Internet - External web service clients may come from outside of the company network.

• Intranet - A company network separated by the external firewall that gives remote workers access to the OHI user interface. This is also where OHI web servers and / or load balancers may be placed. Alternatively, for additional protection, web and load balancing servers may be placed in a separate demilitarized zone (DMZ) where external and internal clients first interact with the OHI environment.

• OHI application server and database zone - OHI application servers, database servers and possibly authentication servers (for example, if a customer chooses to delegate authentication using LDAP servers) typically reside in this zone.

Please make sure that the firewalls used to secure an OHI environment support the HTTP 1.1 protocol; it enables browser cookies and inline data compression for improved performance.

3.1.1 Accessing the User Interface outside the Firewall

OHI Applications' user interfaces are browser-based and will allow remote workers to access the application services. It is recommended that these users access the application from within the company network, secured behind the outside firewall. Virtual Private Network (VPN) technology should be used to allow employees working remotely to access an OHI application. A VPN tunnels outside traffic through the firewall, placing remote workers virtually inside the firewall.

3.1.2 Provide access to OHI Web Services for External Clients

It may be required to give external clients, that are not inside the company firewall, access to OHI web services. In that case, the following aspects have to be taken into account:

• Do not expose the OHI web services directly, always make sure that the web services are fronted by a separate web server / load balancer.

• Messages exchanged between a web service and an external client may contain protected health information; as a minimum security requirement, message traffic must be accessed only through HTTP secured with SSL.

• Apply proper WS-Security policies to enforce authentication and to guarantee integrity and confidentiality of messages.

3.1.3 Configuring SSL

The Secure Sockets Layer (SSL) protocol provides communication security by encrypting traffic across a network in a way designed to prevent eavesdropping and tampering. It uses asymmetric cryptography for privacy and a keyed message authentication code for message reliability. Setting up an SSL-secured connection requires a digital certificate issued by a trusted certificate authority. Self-signed digital certificates should only be used for internal testing.

Caution:

Oracle recommends that all OHI related data communication, whether it is browser or web services based and whether it is within the organization's firewall or accessed through VPN, is at least secured using SSL.

3.1.3.1 Configuring SSL in WebLogic

WebLogic Application Server supports SSL 3.0 and Transport Layer Security (TLS) 1.0 specifications. WebLogic does not support SSL version 2.0 and below.

For information on how to configure SSL in WebLogic please visit the following URLs:

• http://download.oracle.com/docs/cd/E17904_01/web.1111/e13707/ssl.htm#SECMG384

• http://download.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html

• http://download.oracle.com/docs/cd/E17904_01/apirefs.1111/e13952/taskhelp/security/ConfigureKeystoresAndSSL.html

3.1.3.2 Configuring SSL for Authentication: using LDAPS

OHI applications delegate authentication requests using configurable WebLogic authentication providers. Typically, authentication requests are delegated to an LDAP server. WebLogic authentication providers can authenticate using SSL-secured traffic by configuring the LDAP connect string to use LDAPS, e.g. ldaps://<machine>.<domain>:<ssl_port>. The SSL port for the LDAP protocol is usually 636.

This paragraph describes the configuration for enabling SSL encrypted traffic between OHI and Oracle Internet Directory (OID). OID supports three SSL Modes that are listed in the following table.

Table 3-1 Supported SSL Authentication Methods

SSL Authentication Method	Description	Supported by OHI Applications?
Mode 1: No SSL Authentication	Neither the client nor the server authenticates itself to the other. No certificates are sent or exchanged. Only SSL encryption and decryption is used.	No
Mode 2: SSL Server Authentication	The directory server authenticates itself to the client. The directory server sends the client a certificate verifying that the server is authentic.	Yes
Mode 3: SSL Client and Server Authentication	The client and server authenticate themselves to each other and send certificates to each other.	Yes

To use the LDAPS feature, an SSL certificate needs to be obtained and installed on the Directory Server. Recommended steps for configuring Oracle Internet Directory 11g (OID) SSL Server Authentication (mode 2) are listed in this paragraph. The listed process is applicable for OID releases 11.1.1.2 to 11.1.1.4 and is based on Support Article 1203271.1 that is published on the Oracle Support website (and takes precedence over the product documentation). Article 1203271.1 covers steps 1 to 4 in the following list:

1. Support Article 1203271.1 suggests to create an additional OID Instance / Configset. Rationale as given in the article:"By default, the SSL authentication mode is set to authentication mode 1 (encryption only, no authentication). Be sure at least one Oracle Internet Directory server instance has this default authentication mode. Otherwise, you break Oracle Delegated Administration Services and other applications that expect to communicate with Oracle Internet Directory on the encrypted SSL port.". Create an additional OID instance (requires migrating the data of the original instance) or make sure that a configuration set is configured to also support authentication mode 1.

2. Use the Fusion Middleware Enterprise Manager to create a Wallet. For test systems Self-Signed Wallets are sufficient. For production systems Self-Signed Certificates are not recommended: Self-Signed Certificates typically lead to Certificate Trust messages. Users could react to these messages but in OHI Applications the user authentication process will fail as a result of an error in the SSL handshake. Create a proper Wallet for production systems.

   For a production setup, generate a certificate request and send that to a Certificate Authority (CA). Import the SSL certificate that was issued by the CA before continuing with the following step.

3. Enable SSL for the OID server using the Wallet that was created in the previous step.

4. Restart the OID instance.

5. Stop the WebLogic (managed) servers that execute OHI Application.

6. If a Self-Signed certificate was used, prevent Certificate Trust warnings that will break the authentication process by importing the self-signed root certificate in the cacerts certificates store of the JVM that executes the OHI Application.

   • Export the Self-Signed root certificate from the Self-Signed Wallet using the Fusion Middleware Enterprise Manager.

   • Make a backup of the JVM's cacerts file.

   • Import the root certificate into the cacerts certificate store using the keytool. In the following example alias is a self-chosen, meaningful name for the root certificate (note: the alias has to be unique within the cacerts file!)

     keytool -import -trustcacerts -keystore cacerts -storepass changeit -noprompt -alias <alias> -file <path_to_exported_root_certificate_file>
     

7. Start the WebLogic (managed) servers that executes the OHI Application.

8. In the WebLogic Console, in the "Provider Specific" settings tab of the OHIAuthenticationProvider, set the SSLEnabled flag (restart of WebLogic server required).

9. Test the setup. If an additional OID instance was created and the original instance is no longer needed, the original OID Instance / Configuration set can be stopped using opmnctl. Optionally, it can be removed.

3.1.3.3 Configuring SSL for Coherence

OHI uses an Oracle Coherence distributed cache that is shared between multiple cluster nodes. It is expected that all cluster nodes reside in the same security zone, i.e. the OHI application server and database zone. Coherence provides an SSL implementation that secures TCMP communication between cluster nodes that can be enabled if required. For information on how to configure SSL to secure Coherence TCMP traffic please visit the following URLs:

• http://docs.oracle.com/cd/E24290_01/coh.371/e22841/toc.htm