Install and Configure Oracle WebLogic

Oracle Health Insurance runs on an Oracle WebLogic 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 14.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 WebLogic and Creating a Domain

Start with the installation of the Oracle WebLogic. For that purpose make sure to use the Oracle Generic Installer.

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.

Domain Configuration for Oracle Health Insurance

This chapter contains directions for the following topics:

  • Redirecting console log output

  • Setting up the Claims 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 Claims Properties Files

Create a directory that holds the Claims 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-claims.properties.template

Rename the copied ohi-claims.properties.template to ohi-claims.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, the following mechanisms are available:

  • Basic Authentication

  • SSO with SAML 2.0

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

  • Basic Authentication

  • OAUTH 2.0

Basic Authentication

To use Basic Authentication, you must configure the WebLogic security provider to use the CustomIdentityAsserter. To do so, follow the below steps.

CustomIdentityAsserter Configuration Steps

  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 Oracle 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 Providers list, so that the newly created CustomIdentityAsserter provider is at the top.

  8. Save the changes and restart the Oracle WebLogic Server.

CustomIdentityAsserter Specific Properties

Following is the list of the CustomIdentityAsserter specific properties. Ensure that the property ohi.cookie.domain value is changed according to the domain in which the Oracle Health Insurance 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.cookie.domain=<hostname>
    Hostname for which this cookie is created. Once the cookie is created for this hostname then the user can access all the applications deployed on the host.
    Default value: There is no default value. Ensure to change this to the front end hostname used for the Oracle Health Insurance deployment.
    When to change: Change this value before starting the Oracle Health Insurance application.
    Effective: After Restart.

  • ohi.cookie.httponly=true
    Cookie httponly attribute. By default, it is set to true, to prevent client-side scripts from capturing data stored on these cookies.

  • ohi.cookie.secure=false
    Cookie secure attribute. Set the value to true when the application is accessed with https.

  • ohi.cookie.samesite=Lax
    Cookie samesite attribute. Set the value to Strict, to instruct browsers not to share the cookie to other sites, when ohi.cookie.secure=true.

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.logout.url property with appropriate values provided by the configured SAML identity provider.

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 Claims, create a claims_cluster and a claims_coherence_cluster. Associate the claims_cluster with the claims_coherence_cluster using the WebLogic Administration Console: navigate to the claims_cluster, under the Configuration tab select the Coherence sub tab and select the claims_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 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 claims_cluster that consists of the following server members:

  • An Administration Server

  • Two Managed Servers, claims_node1 and claims_node2.

The claims_cluster is associated with an existing claims_coherence_cluster.

  1. For the claims_coherence_cluster define two Well Known Addresses via the WebLogic Administration Console: navigate to the claims_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. Creating Known Addresses
    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 claims_cluster is already associated with the claims_coherence_cluster, the Coherence sub tab already lists the claims_coherence_cluster. Change the settings as follows: .Change in Settings

Settings for …​

Unicast Listen Address

Unicast Listen Port

claims_node1

Name of the host machine that runs the managed server

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

claims_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.

-Dcoherence.mode=prod

Set Environment Variables for the Claims

Environment variables for Claims can be set in the startWebLogic.sh script. An alternative approach (offered as a best practice) is to create a separate shell script named setClaimsEnv.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 setClaimsEnv.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 setClaimsEnv.sh script (which may have been formatted for readability):

# Memory Args
MEM_ARGS="-Xmx4096m"
export MEM_ARGS

# Java Options
JAVA_OPTIONS="${JAVA_OPTIONS} -Dohi.properties.url=file:/config/ohi-claims.properties"
JAVA_OPTIONS="${JAVA_OPTIONS} -Dlogback.configurationFile=/config/logback_claims.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"
JAVA_OPTIONS="${JAVA_OPTIONS} -Dcoherence.distributed.threads=1"
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>/setClaimsEnv.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 the HTTP BASIC authentication must pass the WebLogic Server authentication. Upon successful authentication, the WebLogic Server creates 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 the Oracle Health Insurance applications, the Weblogic Server’s Basic Authentication mechanism must be disabled. To do so, set the domain wide flag enforce-valid-basic-auth-credentials to false. For additional information refer to the WebLogic documentation as well as the Oracle support documents: 2178771.1 and 2235898.1.