Initial Configuration for Oracle Health Insurance Applications in Oracle Fusion Middleware

Logging Configuration

Oracle Health Insurance uses the Logback library for generating log output. That log output is controlled by a logback.xml file that is referenced in the WebLogic Server configuration. Through the configuration file, the logging level can be controlled as well as the output channels (referred to as 'appenders') for log messages. An example of an output channel for logging is a file.

Predefined Logging Configurations

Oracle Health Insurance applications come bundled with a predefined logback configuration called logback.xml.

This default logging configuration can be used as a starting point and may be altered for specific use cases. Use the -Dlogback.configurationFile Java option in the setDomainEnv script to point to a variant of the logback.xml file, for example:

-Dlogback.configurationFile=production-logback.xml
or
-Dlogback.configurationFile=trace-logback.xml

See Logging and Auditing Operations and Logging to a Central Database for more information.

User Timezone

The timezone can be set using the java parameter user.timezone. Use the -Duser.timezone Java option in the setDomainEnv script to set its value. This setting ensures when any data or time is recorded, it is recorded with this timezone setting.

-Duser.timezone=Australia/Sydney

Set Required Defaults

The application requires default settings for a number of objects. Before default settings can be applied, users must be provisioned in order to access the system. Make sure the following prerequisites are met:

Set up users in an external user store like a Directory Server.
Provision users for Oracle Health Insurance applications. For this purpose, a Provisioning service is provided.

Set Up a Directory for File Exchange

In a number of scenarios Oracle Health Insurance processes files, for example for the File Import integration points. It is recommended to set up a shared directory structure that can be accessed by any machine that executes the system.

For example:

For inbound files: /<MOUNT_POINT>/ohi/transfer/in
For outbound or response files: /<MOUNT_POINT>/ohi/transfer/out

These directories can also be made application-specific For additional control.

Authentication, Authorization and User Provisioning

To authenticate and subsequently access an Oracle Health Insurance application, a user needs a user-account in that application. The administration of role-based access rights for the users is handled in Oracle Health Insurance applications as part of their user-account. The User Provisioning supports creating and maintaining user accounts and their access-rights.

Although user accounts are stored in the application, user passwords are not. Oracle Health Insurance delegates authentication to configurable WebLogic Authentication Providers. For more details see User Authentication.

In the authentication process, the user account data that is stored in Oracle Health Insurance is accessed, for example for logging the last time the user successfully logged in to the system.

All pages (other than the login page) and REST APIs are only available to authenticated (and properly authorized) users.

ADF UI pages: users need to authenticate themselves by entering a valid combination of username and password credentials.
JET UI pages: support OAuth2 or the use of Basic Authentication.
REST APIs: support OAuth2 or the use of Basic Authentication.

Seeded Users

During installation, two user accounts are seeded in the OHI_USERS table. Their usage is explained in this paragraph.

System User

The installation creates an account for the Internal System User with the following characteristics:

ID = 10
IND_ACTIVE = Y
DISPLAY_NAME = 'Internal System User'
LOGIN_NAME = null

This user cannot be used to log in to the application via the UI pages, because the LOGIN_NAME is null. The Internal System User is used for internal processing. For example, records created or updated by an Integration Point, will have CREATED_BY and/or LAST_UPDATED_BY = 10 (the id of the internal system user).

Application Specific Setup User

The installation creates an account for the Internal System User with the following characteristics:

ID = 0
IND_ACTIVE = Y
DISPLAY_NAME = this is configured during the initial installation, through ohi_install.cfg
LOGIN_NAME= this is configured during the initial installation, through ohi_install.cfg

Use the Setup User account to provision other user accounts. Before this account can be used it must be available in the user store to which authentication is delegated.

Seeded Access Roles

After the installation new users should be created with appropriate roles assigned to them. For more information on Access Roles and Access Restrictions see the User Access Restriction Model

SETUP_ACCESS_ROLE

The installation assigns the seeded Access Role SETUP_ACCESS_ROLE to the Setup User (login name defined through ohi_install.cfg). This role enables the Setup User to use the Users IP, the accessRoles API and the AccessRoles UI function to further administer roles and users.

ALL_FUNCTIONS_ACCESS_ROLE

The role ALL_FUNCTIONS_ACCESS_ROLE is seeded to facilitate testing of the ADF UI pages. This role gives create, retrieve, update and delete access to all pages of the application. This role is not intended to be used in production environments, therefore it is disabled by default.

After installation, the following steps needs to be taken to set up a new user with the ALL_FUNCTIONS_ACCESS_ROLE granted:

Enable access role ALL_FUNCTIONS_ACCESS_ROLE by accessing the application with a user account that was granted the SETUP_ACCESS_ROLE. Navigate to the Access Roles page and query for the ALL_FUNCTIONS_ACCESS_ROLE. Use the page to enable the role and save the changes
Provision a new user to the Oracle Health Insurance application with the ALL_FUNCTIONS_ACCESS_ROLE granted.

ALL_IP_ACCESS_ROLE

The role ALL_IP_ACCESS_ROLE is seeded to give access to all specific RESTful IP web services, that is all access restrictions of type 'HTTP IP'.

Steps to setup a new user with the ALL_IP_ACCESS_ROLE are the same as previously described for the ALL_FUNCTIONS_ACCESS_ROLE.

ALL_API_ACCESS_ROLE

The role ALL_API_ACCESS_ROLE is seeded to give access to all generic RESTful API web services that is all access restrictions of type 'HTTP API'.

Steps to setup a new user with the ALL_API_ACCESS_ROLE are the same as previously described for the ALL_FUNCTIONS_ACCESS_ROLE.

Keystore Required When Using OAuth2 in Combination With the JET UI

An Access Token Service creates OAuth2 access tokens for use with the JET UI. The Access Token Service makes use of the assertion grant type, with a JSON Web Token as assertion. The Access Token Service signs the token request using a private signing key. The key needs to be securely stored in a keystore.

To create keystores for OAuth2 support, create an application stripe in the WebLogic domain for the Oracle Health Insurance application using WLST. Make sure to start WLST using the $MIDDLEWARE_HOME/oracle_common/common/bin/wlst.sh script. Note that the admin server must be running. Connect to the admin server from WLST and run the following script:

svc = getOpssService(name="KeyStoreService")
svc.createKeyStore(appStripe="claims", name="keystore", password="", permission=true)

Change the value for appStripe, claims in the example, to be the name of the Oracle Health Insurance application as per the following table:

Table 1. Keystore Required When Using OAuth2 in Combination With the JET UI
Oracle Health Insurance Application	appStripe Value
Oracle Health Insurance Authorizations	authorizations
Claims	claims
Oracle Insurance Gateway	oig
Policies	policies
Oracle Health Insurance Product Definition	proddef
Oracle Health Insurance Value-Based Payments	capitation

The response should be:

Keystore created

Also, make sure that data source "opss-data-source" is available for use by the application by targeting it to the WebLogic cluster that runs the application (and not only to the admin server).