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.
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:
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).