Install and Configure Oracle Fusion Middleware

Oracle Health Insurance runs on an Oracle Fusion Middleware Application Server. This is known as the Oracle WebLogic Server. If it runs on more than one managed server or node, the application servers have to be configured as a cluster. Starting with WebLogic version 12.1.x Oracle added a DynamicCluster feature. A dynamic cluster uses a single server template to define configuration for a specified number of generated (dynamic) server instances. In a dynamic cluster, additional dynamic servers can be started without manually configuring them first and adding them to the cluster. Oracle Health Insurance applications are certified to work with both static and dynamic clusters.

This guide assumes experience with the installation and set up of the Oracle WebLogic Server. For details regarding the installation process please consult the product documentation.

The certification information that is available for a specific release through My Oracle Support specifies the required Java version as well as the version of the Oracle WebLogic Server software that must be installed.

It also lists the matching Oracle Application Development Runtime version that is required for any Oracle Health Insurance application.

This chapter briefly outlines the installation of the Oracle WebLogic Server software.

Installing the Oracle Fusion Middleware and Creating a Domain

Start with the installation of the Oracle Fusion Middleware. For that purpose make sure to use the Oracle Fusion Middleware Infrastructure installer.

A WebLogic Domain can be created using the Fusion Middleware Configuration Wizard or by using the WLST scripts. When using the Configuration Wizard, make sure to select the "Oracle JRF" option on the Templates page (next to the Basic WebLogic Server Domain template that is selected by default). The WebLogic Coherence Cluster Extension is selected automatically as it is required with the Oracle JRF template. Any other templates are optional and are not required for running the Oracle Health Insurance applications.

When using the Configuration Wizard, Oracle recommends to accept the default Coherence Cluster Name and the Unicast Listen Port. Coherence Cluster settings are adjusted through the WebLogic Administration Console.

After applying WebLogic patch (WLS PATCH SET UPDATE 12.2.1.4.xxxxxx), a fatal error occurs during the startup of the application. Follow these steps to resolve the error:

  1. Stop the application servers.

  2. Navigate to <MIDDLEWARE_HOME>/oracle_common/modules/thirdparty.

  3. Remove the eight files with /META-INF/groovy/org.codehaus.groovy.runtime.ExtensionModule in their name from groovy-all-2.5.6.jar. You can use the following LINUX or UNIX command to remove the files:

    zip -d groovy-all-2.5.6.jar /META-INF/groovy/org.codehaus.groovy.runtime.ExtensionModule

  4. Restart the application servers.

Domain Configuration for Oracle Health Insurance

This chapter contains directions for the following topics:

  • Redirecting console log output

  • Setting up the Policies properties files

  • Coherence settings

  • Setting the Oracle Health Insurance Domain environment variables

  • Setting the enforce-valid-basic-auth-credentials flag

Redirect the JVM Output to a Log File

By default, the JVM output for a WebLogic server is written to the console. It is recommended to redirect the console output to file.

In the development mode, the default size of a logfile before it is rotated is only 500Kb. Hence, it is also recommended changing the size of the log files before rollover to 10240 Kb and to specify the number of log files that are retained. These configuration settings can be changed through the WebLogic Server Console.

Setting up the Policies Properties Files

Create a directory that holds the Policies properties and the configuration files. This directory is referenced as <CONFIG_ROOT> throughout this document.

Copy the following files that were delivered as part of the specific release from the <OHI_ROOT>/properties directory to the <CONFIG_ROOT>:

  • logback.xml

  • ohi-policies.properties.template

Rename the copied ohi-policies.properties.template to ohi-policies.properties. A description of the properties in the properties file is available elsewhere in this guide.

Also copy file <OHI_ROOT>/util/security/ohi-security.config to the <CONFIG_ROOT>.

Users and Authentication

Authentication is the process of verifying the asserted identity of a service requester. Oracle Health Insurance does not store passwords. It requires an external authentication mechanism. In Oracle Health Insurance the following authentication mechanisms are available for the UI users:

  • LDAP (Internal or External)

  • SSO with SAML 2.0

For API users and integrations, the following mechanisms are available:

  • Basic Auth

  • OAUTH 2.0

LDAP Authentication

Before installing the upgrade for Oracle Health Insurance to the next release, you must do this Custom Asserter setup as the first step, if you are currently using Basic Auth as the authentication mechanism.

Custom Asserter Configuration Steps

The below configuration steps are an onetime activity. Once the configuration is done, there is no need to make any changes in the future releases. But, whenever there is information on the change in the JAR file, then in that release, you need to copy the latest JAR file from the weblogicAsserter folder in the release zip, add the JAR file to the corresponding location mentioned in the configuration step, and restart the WebLogic server.

  1. Add the following Java property to the Domain Environment property:
    -Dweblogic.servlet.useExtendedSessionFormat=true

  2. Copy the JAR file CustomIdentityAsserter.jar, which is present in the weblogicAsserter directory inside the release zip to the WebLogic home. For example,
    path: $ORACLE_HOME/wlserver/server/lib/mbeantypes.

  3. Restart the WebLogic server.

  4. Navigate to Home > Summary of Security Realms > myrealm > Providers.

  5. Create a new provider with the type CustomIdentityAsserter and save it.

  6. Set the Control flag to SUFFICIENT for the LDAP Authentication provider.

  7. Reorder the provider so that the Authentication provider (the Default authenticator/Internal LDAP / External LDAP, or any other authenticator) is at the top of the list.
    The newly created Custom Asserter provider must be second in the Authentication Providers list.

  8. Save the changes and restart WebLogic server.

Custom Asserter System Properties

Following is the list of the Custom Asserter system properties. Ensure that the property ohi.cookie.domain value is changed according to the domain in which the Claims application is running.

  • ohi.contextRoot=/claimsjs
    This property points to the context root of the JET UI.
    Default value: /claimsjs
    When to change: Change this value if the context root of the JET UI is changed.
    Effective: After Restart.

  • ohi.loginpath=/claimsjs/login
    This is the context path of the login module. Modify it whenever the context path of the login module is changed.

  • ohi.ui.logout.url=/claimsjs/login/logout
    This is the context path of the logout URL. Modify it whenever the context path of the login module is changed. Replace /claimsjs/login/ with the new context path.

  • ohi.custom.cookie.password=OhISeCrEt2_0_2_3
    The password which is used to encrypt the cookie is created for perimeter authentication.
    Default value: OhISeCrEt2_0_2_3
    When to change: Change this value if you want a strong password.
    Effective: After Restart.

  • ohi.cookieMaxAge=60
    The expiry time for the cookie created for perimeter authentication, but WebLogic creates another cookie on top of this. Hence, setting this expiry does not have much impact on the application.
    Default value: 60

  • ohi.cookie.domain=localhost
    Domain for which this cookie is created. Once the cookie is created for this domain then the user can access all the applications deployed in this domain without the need to authenticate again and again after first time.
    Default value: There is no default value. Ensure to change it to the domain of the Claims application.
    When to change: Change this value before starting the Claims Web application.
    Effective: After Restart.

  • ohi.cookie.httponly=true
    Cookie http only attribute. Read online about this cookie attribute and change it accordingly.

  • ohi.cookie.secure=false
    Cookie secure attribute. Read online about this cookie attribute and change it accordingly.

  • ohi.cookie.samesite=Lax
    Cookie same site attribute. Read online about this cookie attribute and change it accordingly.

  • ohi.cookie.path=/
    Cookie path attribute. Read online about this cookie attribute and change it accordingly.

SSO with SAML 2.0

Security Assertion Markup Language (SAML) enables cross-platform authentication between Web applications or Web services running in an Oracle WebLogic Server domain and Web browsers or other HTTP clients. When users are authenticated at one site that participates in a single sign-on (SSO) configuration, they are automatically authenticated at other sites in the SSO configuration and do not need to log in separately.

See Configuring SAML 2.0 Services for more info.

For the single logout functionality, update the ohi.ui.logouturl property with appropriate values provided by the configured SAML identity provider.

See Application Properties for more info on how to set properties.

OAUTH 2.0

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service. This access can be granted on behalf of a resource owner, by orchestrating an approval interaction between the resource owner and the HTTP service. Alternatively, the third-party application can also obtain access on its own behalf.

See Configuring the Oracle Identity Cloud Integrator Provider for more info.

Coherence settings

Oracle Health Insurance applications use Oracle Coherence. The IT infrastructure on which the system is installed determines the configuration for Oracle Coherence. Coherence Cluster settings are maintained using the WebLogic Administration Console. This paragraph describes the following configuration options:

  • Control multiple Coherence clusters that are spread across multiple machines

  • Control multiple Coherence clusters that are executed on one machine

  • Specific settings for running Coherence in a Production environment

Define a Coherence Cluster for Oracle Health Insurance

Oracle recommends creating an application-specific Coherence cluster that is associated with the (application-specific) WebLogic Cluster in which the Oracle Health Insurance application is executed. For example: for Policies, create a policies_cluster and a policies_coherence_cluster. Associate the policies_cluster with the policies_coherence_cluster using the WebLogic Administration Console: navigate to the policies_cluster, under the Configuration tab select the Coherence sub tab and select the policies_coherence_cluster from the Coherence Cluster drop down list. Make sure to enable the local storage.

Run Multiple Coherence Clusters of Multiple JVMs on the Same Machine or Same Set of Machines

For controlling which JVMs can join in a particular Coherence cluster, the following options are available:

  • Use multicast addressing and have every member that needs to join the cluster define the cluster name

  • Use the Coherence Well Known Addresses (WKA) feature

Use a feature of choice to:

  • Control multiple Coherence clusters that are spread across multiple machines

  • Control multiple Coherence clusters that are executed on one machine

  • Example: use Well Known Addresses to Control which Members are allowed to join a Coherence Cluster

  • Assuming a WebLogic cluster policies_cluster that consists of the following server members:

  • An Administration Server

  • Two Managed Servers, policies_node1 and policies_node2.

The policies_cluster is associated with an existing policies_coherence_cluster.

  1. for the policies_coherence_cluster define two Well Known Addresses via the WebLogic Administration Console: navigate to the policies_coherence_cluster, under the Configuration tab select the Well Known Addresses sub tab. Click New to create two Well Known Addresses with the following characteristics:

    Table 1. Run Multiple Coherence Clusters of Multiple JVMs on the Same Machine or Same Set of Machines
    Name Listen Address Listen Port

    wka1

    Name of the host machine that runs the managed server

    A unique listen port, for example, 27111

    wka2

    Name of the host machine that runs the managed server

    A unique listen port, for example, 27112

  2. for each Managed Server, navigate to the Settings page, under the Configuration tab select the Coherence sub tab. Given that policies_cluster is already associated with the policies_coherence_cluster, the Coherence sub tab already lists the policies_coherence_cluster.

Table 2. Change the Settings as Follows:
Settings for …​ Unicast Listen Address Unicast Listen Port

policies_node1

Name of the host machine that runs the managed server

wka1 port, that is, 27111 (as used in the example)

policies_node2

Name of the host machine that runs the managed server

wka2 port, that is, 27111 (as used in the example)

Make sure to activate the changes that were made.

For additional information refer to the Fusion Middleware documentation on Administering Clusters for Oracle WebLogic Server.

Specific Settings for Running Coherence in a Production Environment

By default, Oracle Coherence runs in the Development mode. The production checklist in the Coherence documentation states that it is recommended to use the development mode for all pre-production activities, such as development and testing. This is an important safety feature, because Coherence automatically prevents these nodes from joining a production cluster. The production mode must be explicitly specified when using Coherence in a production environment.

In the Production environment (and only in the Production environment), the system property tangosol.coherence.mode must be set to value prod in the script that is used to start Coherence nodes.

-Dtangosol.coherence.mode=prod

Set Environment Variables for the Policies

Environment variables for Policies can be set in the startWebLogic.sh script. An alternative approach (offered as a best practice) is to create a separate shell script named setPoliciesEnv.sh in a directory (referred to hereafter as <SET_ENV_VAR_DIR>). Rationale:

  • The startWebLogic.sh file is generated by the WLS and large (clutters the view).

  • The startWebLogic.sh file can be changed by the WebLogic if the cluster configuration changes. A separate setPoliciesEnv.sh file shields from these changes.

Make sure that <SET_ENV_VAR_DIR> is a shared directory for all the managed servers in the cluster. The following is a sample setPoliciesEnv.sh script (which may have been formatted for readability):

# Memory Args
MEM_ARGS="-Xmx4096m"
MEM_ARGS="${MEM_ARGS} -XX:+UseG1GC"
export MEM_ARGS

# Java Options
JAVA_OPTIONS="${JAVA_OPTIONS} -Dohi.properties.url=file:/config/ohi-policies.properties"
JAVA_OPTIONS="${JAVA_OPTIONS} -Dlogback.configurationFile=/config/logback_policies.xml"
JAVA_OPTIONS="${JAVA_OPTIONS} -Djava.security.auth.login.config=/config/ohi-security.config"
JAVA_OPTIONS="${JAVA_OPTIONS} -Dtangosol.coherence.mode=prod"
JAVA_OPTIONS="${JAVA_OPTIONS} -Dcom.sun.org.apache.xml.internal.dtm.DTMManager=
  com.sun.org.apache.xml.internal.dtm.ref.DTMManagerDefault"
JAVA_OPTIONS="${JAVA_OPTIONS} -Djavax.xml.datatype.DatatypeFactory=
  com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl"
JAVA_OPTIONS="${JAVA_OPTIONS} -Djavax.xml.stream.XMLInputFactory=
  com.sun.xml.internal.stream.XMLInputFactoryImpl"
JAVA_OPTIONS="${JAVA_OPTIONS} -Djavax.xml.stream.XMLOutputFactory=
  com.sun.xml.internal.stream.XMLOutputFactoryImpl"
JAVA_OPTIONS="${JAVA_OPTIONS} -Djavax.xml.stream.XMLEventFactory=
  com.sun.xml.internal.stream.events.XMLEventFactoryImpl"
export JAVA_OPTIONS

# To make Jersey filters that set certain CORS related HTTP Headers work
JAVA_OPTIONS="${JAVA_OPTIONS} -Dsun.net.http.allowRestrictedHeaders=true"

# Optional settings for JMX management
JAVA_OPTIONS="${JAVA_OPTIONS} -Dcom.sun.management.jmxremote.authenticate=false"
JAVA_OPTIONS="${JAVA_OPTIONS} -Dcom.sun.management.jmxremote.ssl=false"
JAVA_OPTIONS="${JAVA_OPTIONS} -Djavax.management.builder.initial=
weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder"
export JAVA_OPTIONS

# Optional settings to enable monitoring Coherence through JMX
JAVA_OPTIONS="${JAVA_OPTIONS} -Dtangosol.coherence.management=all"
JAVA_OPTIONS="${JAVA_OPTIONS} -Dtangosol.coherence.management.remote=true"
export JAVA_OPTIONS

Use the tangosol.coherence.mode property for production environments only.

Go to the domain directory and edit bin/startWebLogic.sh script. Add the following line (highlighted below) at the beginning as shown in this sample:

# Call setDomainEnv here.

DOMAIN_HOME="/home/domains/ohi_domain"

. ${DOMAIN_HOME}/bin/setDomainEnv.sh noderby $*

if [ "${SERVER_NAME}" = "<ohi admin server name>" ] ; then
   MEM_ARGS="-Xmx1024m"
   export MEM_ARGS
else
   . <SET_ENV_VAR_DIR>/setPoliciesEnv.sh ${SERVER_NAME}
fi

SAVE_JAVA_OPTIONS="${JAVA_OPTIONS}"

Setting the Enforce-valid-basic-auth-credentials Flag

RESTful services in the Oracle Health Insurance applications' HTTP API use Basic Authentication as the default authentication mechanism. The RESTful API requests that use HTTP BASIC authentication must pass the WebLogic Server authentication. Upon successful authentication, the WebLogic Server creates the HTTP session objects in the JVM memory. The default session-timeout value in the WebLogic Server is 3600 seconds, so the HTTP session objects are invalidated/GC’ed only after 3600 seconds.

Since Basic Authentication is handled by Oracle Health Insurance applications, Weblogic Server’s Basic Authentication mechanism should be disabled. To do so, set the domain wide flag enforce-valid-basic-auth-credentials to false. For more information, please check the https://docs.oracle .com/middleware/1221/wls/SCPRG/thin_client.htm#SCPRG150[WebLogic documentation] as well as Oracle support documents: 2178771.1 and 2235898.1.

Limited Support for the X Window System

For displaying gauges in the UI pages on systems that do not have the X Windows system or have limited access to it add the following JAVA_OPTIONS option:

JAVA_OPTIONS="$JAVA_OPTIONS -Djava.awt.headless=true"

See the Java documentation for more information. Typically, on a system that lacks X Windows support and that does not have this option specified, gauges are not displayed correctly and the following exception is included in the logs (formatted for displaying it in this guide):

<Aug 31, 2011 12:39:00 PM CEST> <Error> <oracle.adfinternal.view.faces.config.rich.RegistrationConfigurator>
 <BEA-000000> <ADF_FACES-60096:Server Exception during PPR, #1 javax.servlet.ServletException:
  java.lang.InternalError: Can't connect to X11 window server using ':0' as the value of the DISPLAY variable.

Configure Premium Calculation to Apply Registrations

When registrations are to be applied, add environment variable "ohi.policies.calculate.calculationperiods.applyregistrations" with value "true". This can be added to the JAVA_OPTIONS in the setPoliciesEnv script file.