Skip Headers
Oracle® Retail Merchandising Security Guide
Release 15.0
E65442-01
  Go To Table Of Contents
Contents

Previous
Previous
 
Next
Next
 

3 Post Installation of Retail Infrastructure in WebLogic

This chapter describes the post installation steps for secured setup of Oracle Retail infrastructure in WebLogic.

The following topics are covered in this chapter:

Retail Application Specific Post installation Steps for Security

See the following sections for steps to improve security after an Oracle Retail Application has been installed.

Batch Set Up for SSL Communication

Java batch programs communicate with Java applications deployed in WebLogic. For example, Oracle Retail Price Management (RPM) and Oracle Store Inventory Management (SIM). The communication needs to have SSL handshake with the deployed application. You need to import the SSL Certificates into the JAVA_HOME/jdk/jre/lib/security/cacerts keystore for successful running of the application batches.

Example 3-1 Importing certificates into JDK keystore

/u00/webadmin/product/jdk/jre/lib/security> cp -rp cacerts cacerts_ORIG
 
/u00/webadmin/product/jdk/jre/lib/security> keytool -import -trustcacerts -alias  verisignclass3g3ca -file ~/ssl/Primary.pem -keystore cacerts
 
/u00/webadmin/product/jdk/jre/lib/security> keytool -import -trustcacerts -alias  oracleclass3g3ca -file ~/ssl/Secondary.pem -keystore cacerts
 
/u00/webadmin/product/jdk/jre/lib/security> keytool -import -trustcacerts -alias  hostname -file ~/ssl/cert.cer -keystore cacerts

Note:

The default password of JDK keystore is changeit.

Oracle Business Intelligence (BI) Publisher - Disable Guest User - Optional

The guest account in Oracle Business Intelligence (BI) publisher is used for public facing reports that anyone can see. Disabling this account forces all users to supply their credentials before accessing any information. Disabling guest user enhances security of BI Publisher. However, application which requires guest user will have reporting feature which may cease to function after making this change. For example, RMS reports.

Perform the following steps to disable the guest user:

  1. Log in to BI Publisher with user having Administrator privileges.

  2. Navigate to Administration > Security Configuration.

  3. Deselect Allow Guest Access.

    Figure 3-1 Administration Window

    Surrounding text describes Figure 3-1 .
  4. Save and restart the BI Publisher instance.

RMS - Forms Timeout Setting - Optional

Oracle Forms can be configured to timeout based on user idle time.

You need to set the following parameters:

  1. FORMS_TIMEOUT - This parameter is set RMS/RWMS env file created at <DOMAIN_HOME>/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.2/config directory

    The default value for forms timeout is 15 and Valid Values range from 3 to 1440 (1 day).

    This parameter specifies the amount of time in elapsed minutes before the Form Services process is terminated when there is no client communication with the Form Services. Client communication can come from the user doing some work, or from the Forms Client heartbeat if the user is not actively using the form.

  2. HeartBeat - This parameter is set in formsweb.cfg file located in DOMAIN_HOME>/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/config directory.

    The default value for HeartBeat is 2 and Valid Values range from 1 to 1440 (1 day).

    Example:

    [rmsFqa3]
    envfile=./develop/rmsFqa3.env
    width=950
    height=685
    separateFrame=true
    form=rtkstrt.fmx
    lookAndFeel=Oracle
    colorScheme=swan
    archive=frmall.jar,icons.jar
    imageBase=codebase
    heartbeat=12
    

    Note:

    For more information on the above parameters and additional options, see the Oracle Support Note: Description List For Parameters Affect Timeout In Webforms [ID 549735.1].

Asynchronous Task JMS Queue Security

This section describes the steps for adding security to the asynchronous task JMS queue. Securing the queue will allow only recognized users of the Retail Application to publish tasks to the JMS queue.

Verifying and Creating Required Async Task Job Role and User

Securing the JMS async task queue requires a special enterprise role and a special user to exist in the retailer's Oracle Internet Directory (OID) instance.

The RETAIL_ASYNC_TASK_JOB is an enterprise role that will be used to group users who will have access to the asynchronous task queue.

The RETAIL _ASYNC_TASK_USER is a special user Retail Applications can use as a principal for executing their message-driven-bean-based consumer processes. This user is a member of the RETAIL_ASYNC_TASK_JOB.

The RETAIL_ASYNC_TASK_JOB and RETAIL_ASYNC_TASK_USER are included as part of the Retail Default Security Reference Implementation installed as part of the Retail Application.

Verify the existence of the job and user in the OID instance. You need to create them if they do not exist.

Securing the Asynchronous Task JMS Queue

Securing the queue can be done through the Weblogic Administration Console by adding a JMS Queue Scoped role.

  1. Log into the WebLogic Administration Console.

  2. Navigate to the JMS Module where the asynchronous task queue belongs to and go to the module's Security tab.

  3. Under the Roles section, add a new JMS Queue Scoped Roles.

    Figure 3-2 Adding a new JMS Queue Scoped Roles

    Surrounding text describes Figure 3-2 .
  4. Specify a name for the JMS Queue Scoped Role. The suggested naming convention is [AppCode]AsyncJMSQueueAccessRole]. For example, AllocAsyncJMSQueueAccessRole. The JMS Queue Scoped Role will be created.

    Figure 3-3 JMS Queue Scoped Role

    Surrounding text describes Figure 3-3 .
  5. Navigate back to the JMS Module's Security tab.

  6. Click the JMS Queue Scoped role that was created and add a Group condition for RETAIL_ASYNC_TASK_JOB.

    Figure 3-4 Adding a Group condition for RETAIL_ASYNC_TASK_JOB

    Surrounding text describes Figure 3-4 .
  7. Navigate back to the JMS Module's Security tab.

  8. Go to the Policies section.

    Figure 3-5 Policies Tab

    Surrounding text describes Figure 3-5 .
  9. Add a new Role based condition specifying the JMS Queue Role created in the previous step.

    Figure 3-6 Adding a New Role

    Surrounding text describes Figure 3-6 .
  10. Save the changes. The queue is now secured.

  11. Proceed to the next section to allow the Retail Web Application to publish tasks to the queue.

Allowing Publishing to a Secured Asynchronous Task JMS Queue

Once the Asynchronous Task Queue has been secured with a JMS Queue Scoped Role as described in the previous section, further configuration is required to allow users of the Retail web application to publish tasks to the queue.

The JMS Queue Scoped Role was created to include an enterprise role, RETAIL_ASYNC_TASK_JOB. Any users belonging to this enterprise role will be given access to publish tasks to the queue.

Instead of assigning users directly to the RETAIL_ASYNC_TASK_JOB, it is recommended that applications should identify specific enterprise job roles in their system whose users will be allowed to perform asynchronous processing. Those job roles should be configured to extend from the RETAIL_ASYNC_TASK_JOB group.

See the Oracle Internet Directory documentation for details on how to extend one group to another.

Hardening Use of Headers and Transport Layer Security

This section describes the steps for adding security headers in Web server layer and transport security settings in the Retail Applications web.xml file.

Virtual Host Configuration

Navigate to Web server configuration file and add the following header configurations by restarting Web server:

# Header Settings to make sure no-store is active 
 
<IfModule mod_headers.c>
    Header set Cache-Control "private, no-cache, no-store, proxy-revalidate, no-transform"
    Header set Pragma "no-cache"
</IfModule>
     
# Guarantee HTTPS for 1 Year including Sub Domains
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
# The HTTP header, X-Frame-Options must be in use for sites where content should not be viewed in a 3rd-party X-Frame. 
# A common middle ground is to send SAMEORIGIN, meaning only websites of the same origin may frame it. 
Header always append X-Frame-Options SAMEORIGIN

Retail Applications web.xml Configurations

  1. Extract the respective Retail applications.

  2. Navigate to web.xml file in WEB-INF directory of the application war file.

  3. Add the following contents:

    <security-constraint>
    <web-resource-collection>
    <web-resource-name>All</web-resource-name>
    <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <user-data-constraint>
    <description>USE SSL</description>
    <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
    </security-constraint>