Initial configuration for OHI Components in Oracle Fusion Middleware
Logging configuration
Oracle Health Insurance makes use of 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
The OHI Components Operations Guide describes log files and how to control log output.
User Timezone
Timezone can be set using 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 OHI Components applications. For this purpose, a Provisioning service is provided.
Set up a directory for File Exchange
In a number of scenarios OHI Components process 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
For additional control these directories could also be made application-specific.
Authentication and User Provisioning
Before users can access an OHI Components application, the following prerequisites must be met:
-
A user must be provisioned to access an OHI Components application. The main purpose of Oracle Health Insurance user accounts is authorization: the administration of (role-based) access rights for users is handled in Oracle Health Insurance applications.
-
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.
All pages (other than the login page) and REST APIs are only available to authenticated (and properly authorized) users.
The following paragraphs provide details on authentication and provisioning.
Delegating Authentication to an LDAP Authentication Provider
Although user accounts are stored in the application, user passwords are not. OHI Components delegates authentication to configurable WebLogic Authentication Providers. WebLogic comes with various predefined Authentication Providers, e.g. to support LDAP based authentication. The Authentication Providers can be configured via the WebLogic Console.
Users in the LDAP server are expected to be defined using the industry standard inetOrgPerson object class (which is derived from the organizationalPerson object class). Typically, in that class, the properties uid and userpassword are used to store the credentials used for logging in.
The following picture shows the flow of the authentication process:
Credentials are passed by the user via the application’s Login page or included in the request header of a RESTful web service request.
In the authentication process, the user account data that is stored in OHI Components is accessed, for example for logging the last time the user successfully logged in to the system. Before someone can authenticate and subsequently access OHI Components, an account has to be set up. For that purpose, OHI Components offer a user provisioning service.
LDAP Authentication Providers Configuration for Performance
WebLogic Server supports the use of several ways to improve the performance of LDAP Authentication providers, such as optimizing settings for the group membership caches, connection pool size, and user cache. See the WebLogic documentation on Improving the Performance of LDAP Authentication Providers to configure the following:
| Area | Field | Suggested Values |
|---|---|---|
Connection Pool |
Connection Pool Size |
100 |
LDAP Server Cache |
Cache Enabled |
Checked (or Enabled) |
Cache Size |
3200 kilobytes |
|
Cache TTL |
Specify a time-to-live value that matches the Group Hierarchy Cache TTL value (see Optimizing the Group Membership Caches). Suggested value: 6000 seconds. |
|
Results Time Limit |
1000 ms |
Make sure to restart WebLogic Server for the changes to take effect.
Seeded Users
During installation, two user accounts are seeded in the OHI_USERS table. Their usage is explained in this paragraph.
System User
An account for the Internal System User is created in the OHI_USERS table 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
An account for the Internal System User is created in the OHI_USERS table 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
The Setup user account can be used to provision other user accounts. Note that before this account can be used it must be available in the user store to which authentication is delegated.
Seeded Access Roles
After installation new users should be created with appropriate roles assigned to them.
During installation the Setup User (login name defined through ohi_install.cfg) is assigned the seeded SETUP_ACCESS_ROLE. This role enables a user to use the users IP, the accessRoles API and the AccessRoles UI function to further administer roles and users.
| Access Role Attribute | Value |
|---|---|
Code |
SETUP_ACCESS_ROLE |
Name |
Setup Access Role |
Description |
System role that allows setting up access roles |
Active |
Y |
Enabled |
Y |
Ohi specific? |
Y |
Granted Access Restrictions
| Access Restriction |
|---|
AccessRoles |
accessroles API |
users IP |
To facilitate testing, role ALL_FUNCTIONS_ACCESS_ROLE is seeded also. This role gives access to all pages of the application. This role is not intended to be used in production environments, therefore it is disabled by default.
| Access Role Attribute | Value |
|---|---|
Code |
ALL_FUNCTIONS_ACCESS_ROLE |
Name |
All Functions Access Role |
Description |
System role that gives access to all pages (disabled by default) |
Active |
Y |
Enabled |
N |
OHI specific? |
Y |
| Access Restriction Grant Attribute | Value |
|---|---|
Access Restriction |
All access restrictions of type 'Function' |
Create? |
Y |
Retrieve? |
Y |
Update? |
Y |
Delete? |
Y |
OHI specific? |
Y |
After installation, the following steps needs to be taken to setup a new user with the ALL_FUNCTIONS_ACCESS_ROLE granted:
-
Provision a new user with the ALL_FUNCTIONS_ACCESS_ROLE granted to the OHI Components application.
-
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.
The role ALL_IP_ACCESS_ROLE gives access to specific RESTful IP web services.
| Access Role Attribute | Value |
|---|---|
Code |
ALL_IP_ACCESS_ROLE |
Name |
All Integration Point Access Role |
Description |
System role that gives access to all integration points |
Active |
Y |
Enabled |
N |
OHI specific? |
Y |
| Access Restriction Grant Attribute | Value |
|---|---|
Access Restriction |
All access restrictions of type 'HTTP IP' |
Create? |
Y |
Retrieve? |
Y |
Update? |
Y |
Delete? |
Y |
OHI specific? |
Y |
Steps to setup a new user with the ALL_IP_ACCESS_ROLE are the same as previously described for the ALL_FUNCTIONS_ACCESS_ROLE.
The role ALL_API_ACCESS_ROLE gives access to generic RESTful API web services.
| Access Role Attribute | Value |
|---|---|
Code |
ALL_API_ACCESS_ROLE |
Name |
All generic APIs Access Role |
Description |
System role that gives access to all API services |
Active |
Y |
Enabled |
N |
OHI specific? |
Y |
| Access Restriction Grant Attribute | Value |
|---|---|
Access Restriction |
All access restrictions of type 'HTTP API' |
Create? |
Functionally defined per API |
Retrieve? |
Y |
Update? |
Functionally defined per API |
Delete? |
Functionally defined per API |
OHI specific? |
Y |
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 OHI 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 OHI application as per the following table:
| OHIApplication | appStripe Value |
|---|---|
OHI Authorizations |
authorizations |
OHI Claims Adjudication and Pricing |
claims |
OHI Insurance Gateway |
oig |
OHI Enterprise Policy Administration |
policies |
OHI Product Definition |
proddef |
OHI 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).