Overview of Security Features

1 Overview of Security Features

This chapter provides an overview of the security features included with Oracle Retail Insights.

Retail Analytics and Planning

As part of the Retail Analytics and Planning cloud services, the latest version of Retail Insights shares many common components, tools, and processes with other applications like AI Foundation Cloud Services. This document is specific to the version of RI deployed in 1^st Generation architecture, which is not part of the RAP platform and maintains its own deployment model and security features.

Retail Insights Physical Deployment

The following diagram provides a high-level overview of the physical deployment of Retail Insights.

Figure 1-1 Physical Deployment

Retail Insights

The PC user interface for the Oracle Retail Insights application is web-based, normally accessed through a browser. RI does not provide it’s own user interface, but instead leverages the Oracle Analytics Server product for all it’s interface needs.

The minimal configuration of the Oracle Retail Insights application runs on three types of servers: one for the reporting user interface via Oracle Analytics Server (OAS), one for the batch execution via Oracle Data Integrator (ODI), and one for the Oracle database. The batch execution and ODI metadata can be on the same server with Oracle database. Using same Oracle database server for ODI metadata and RI data mart can improve batch performance due to less network traffic. The storage of executables, scripts, configurations and data for each can reside on a central mirrored disk array cabinet unit or can be segregated by server type, with the file system configured as a shared mount point for relevant servers. All the servers and disk storage units are inter-connected by one or more high speed optical fiber channels where appropriate to insure quickest data communication relative to time critical processes occurring on each server. For connectivity to Retail Insights data source systems and Retail Insights hosted in the corporate data center, a LAN is sufficient. And for systems external to the data center, a WAN is usually sufficient.

The data aggregation logic is found on the batch server while the reporting logic for the application is customized by users and stored on the application server.

The U.I. server setup involves Oracle Analytic Server (OAS), which support horizontal scaling to provide some higher availability, load balancing and fail-over, and visualization. To fully enable clustering requires a Web Load Balancer servicing HTTP requests from PC clients, and the cohabitation of OAS on the multiple servers.

The database server hosts the Oracle database instance for the application. The database server can optionally be RAC enabled, using Oracle Clusterware, to provide high availability and fail-over, without which a fail-over backup server (potentially idle) would be required.

The Retail Insights application has numerous ODI batch jobs. The scheduling can be performed by the same scheduler installed for the core Merchandising applications. The processing architectures of most batch jobs do not naturally lend themselves to horizontal scaling across multiple servers. However in the event of a batch server hardware failure, a backup server connected to the same file system may be needed to facilitate quicker restart of aborted jobs. Alternatively, batch jobs could be executed on the database server and/or ODI batch server if ODI is installed on the different server with Retail Insights database server, but with a RAC setup the load balancing of multiple jobs, across multiple servers is not straightforward. In addition, jobs run on RAC database servers, will cause uneven contention for resources with the Oracle database instances that would partially defeat the load balancing efforts of RAC for Oracle database instances.

All of the batch jobs except data mining related batch jobs should run daily during a nightly batch window with no user access availability for the application. Data mining batch jobs should run weekly.

Oracle Analytics

The standard reporting tool for Retail Insights is Oracle Analytics Server (OAS). The version of OAS used is the standalone enterprise edition platform, not the cloud-hosted OCI version (known as OAC). Using OAS allows for full control over the configurations, metadata, and support process within our own hosted cloud environments.

Dependent Applications

Oracle® Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition
Oracle WebLogic Server Documentation Library
Oracle® Database 2 Day + Security Guide, 12c Release 1
Oracle® Fusion Middleware Developer's Guide for Oracle Data Integrator

Secured setup of Retail Insights Infrastructure in WebLogic

Retail Insights is deployed in Oracle Analytics Server (OAS) on top of WebLogic (WLS). The security of Oracle Analytics can be configured at different levels based on security requirements.

This document provides steps of securing the WebLogic infrastructure where OAS has been installed.

To learn about security at different layers of OAS, please refer to Managing Security for Oracle Analytics Server.

WebLogic Server supports SSL on a dedicated listen port. Oracle Analytics can be configured to use SSL as well. To establish an SSL connection, a Web browser connects to WebLogic Server by supplying the SSL listen port and the HTTPs protocol in the connection URL, for example, https://myserver/analytics.

Retail Insights setup is supported in WebLogic in secured mode. For enterprise deployment, it uses SSL certificates signed by certificate authorities. The process in the following sections describes how SSL certificates are obtained and used with WebLogic. No action is needed outside of Oracle when interacting with OAS deployed as part of Retail Insights in the cloud, this is mainly for informational purposes.

Note:

Separate signed SSL certificates needs to be obtained for each host where application is being deployed.

Obtain an SSL Certificate and Setup a Keystore

Obtain an identity (private key and digital certificates) and trust (certificates of trusted certificate authorities) for WebLogic Server. Use the digital certificates, private keys, and trusted CA certificates provided by the WebLogic Server kit, the CertGen utility, Sun Microsystem's keytool utility, or a reputable vendor such as Entrust or Verisign to perform this step.
1. Set appropriate JAVA_HOME and PATH to java.
  
  Example:
```
export JAVA_HOME=/u00/webadmin/product/jdk
export PATH=$JAVA_HOME/bin:$PATH
```
2. Create a new keystore.
```
keytool -genkey -keyalg RSA -keysize 2048 -keystore <keystore> -alias <alias>
```
  Example:
```
keytool -genkey -keyalg RSA -keysize 2048 -keystore [SERVERNAME].keystore -alias [SERVERNAME]
```
3. Generate the signing request.
```
keytool -certreq -keyalg RSA -file <certificate request file> -keystore <keystore> -alias <alias>
```
  Example:
```
keytool -certreq -keyalg RSA -file [SERVERNAME].csr -keystore [SERVERNAME].keystore -alias [SERVERNAME]
```
4. Submit the certificate request to Certificate authority.
Store the identity and trust. Private keys and trusted CA certificates which specify identity and trust are stored in a keystore.

In following examples, we are using same keystore to store all certificates.
1. Import the root certificate into the keystore.
  
  Example:
```
keytool -import -trustcacerts -alias verisignclass3g3ca -file Primary.pem-keystore  [SERVERNAME].keystore
```
2. Import the intermediary certificate (if required) into the keystore.
  
  Example:
```
keytool -import -trustcacerts -alias oracleclass3g3ca -file Secondary.pem-keystore  [SERVERNAME].keystore
```
3. Import the received signed certificate for this request into the keystore.
  
  Example:
```
keytool -import -trustcacerts -alias [SERVERNAME] -file cert.cer -keystore
```

Configure the Application Server for SSL

Follow the below steps to configure both the Administration server and managed server of Oracle Analytics (bi_server1). You can choose to disable the non-SSL ports (HTTP). It is highly recommended to secure the Node Manager. The steps to secure Node Manager as provided in the next section.

Configure the identity and trust keystores for WebLogic Server in the WebLogic Server Administration Console.
1. In the Change Center of the Administration Console, click Lock & Edit.
2. In the left pane of the Console, expand Environment and select Servers.
3. Click the name of the server for which you want to configure the identity and trust keystores. For Forms server, it would be typically WLS_FORMS.
4. Select Configuration > Keystores.
5. In the Keystores field, select Custom Identity and Custom Trust.
6. In the Identity section, define attributes for the identity keystore.
  
  Custom Identity Keystore: The fully qualified path to the identity keystore created above.
  
  Custom Identity Keystore Type: The type of the keystore. Generally, this attribute is Java KeyStore (JKS); if left blank, it defaults to JKS.
  
  Custom Identity Keystore Passphrase: The password you will enter when reading or writing to the keystore. This attribute is optional or required depending on the type of keystore. All keystores require the passphrase in order to write to the keystore. However, some keystores do not require the passphrase to read from the keystore. WebLogic Server only reads from the keystore so whether or not you define this property depends on the requirements of the keystore.
7. In the Trust section, define properties for the trust keystore.
  
  Custom Trust Keystore: The fully qualified path to the trust keystore.
  
  Custom Trust Keystore Type: The type of the keystore. Generally, this attribute is JKS; if left blank, it defaults to JKS.
  
  Custom Trust Keystore Passphrase: The password you will enter when reading or writing to the keystore. This attribute is optional or required depending on the type of keystore. All keystores require the passphrase in order to write to the keystore. However, some keystores do not require the passphrase to read from the keystore. WebLogic Server only reads from the keystore so whether or not you define this property depends on the requirements of the keystore.
8. Click Save.
9. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
  
  Not all changes take effect immediately-some require a restart.
  
  Figure 1-2 Keystores Window
  
  Note:
  
  See "Configure Keystores" in the Administration Console Online Help for more information.
Set SSL configuration options for the private key alias and password in the WebLogic Server Administration Console.
1. In the Change Center of the Administration Console, click Lock & Edit.
2. In the left pane of the Console, expand Environment and select Servers.
3. Click the name of the server for which you want to configure the identity and trust keystores.
4. Select Configuration > SSL.
5. In the Identity and Trust Locations, defaults to Keystores.
6. In the Private Key Alias, type the string alias used to store and retrieve the server's private key.
7. In the Private Key Passphrase, provide the keystore attribute that defines the passphrase used to retrieve the server's private key.
8. Save the changes.
9. Click on Advanced section of SSL tab.
10. In the Hostname Verification, select as None. This specifies to ignore the installed implementation of the weblogic.security.SSL.HostnameVerifier interface (this interface is generally used when this server is acting as a client to another application server).
11. Save the changes.
  
  Figure 1-3 SSL Window
  
  Note:
  
  See "Configure SSL" in the Administration Console Online Help for additional information.

Post Setup

All the server SSL attributes are dynamic; when modified via the Console, they cause the corresponding SSL server or channel SSL server to restart and use the new settings for new connections. Old connections will continue to run with the old configuration. To ensure that all the SSL connections exist according to the specified configuration, you must reboot WebLogic Server.

Use the Restart SSL button on the Control: Start/Stop page to restart the SSL server when changes are made to the keystore files and need to be applied for subsequent connections without rebooting WebLogic Server.

Upon restart you can see similar entries in the log.

<Mar 11, 2013 5:18:27 AM CDT> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to RESUMING>
<Mar 11, 2013 5:18:27 AM CDT> <Notice> <Server> <BEA-002613> <Channel
"DefaultSecure" is now listening on ip.to.your.server:57002 for protocols iiops, t3s, ldaps, https.>
<Mar 11, 2013 5:18:27 AM CDT> <Notice> <Server> <BEA-002613> <Channel
"DefaultSecure[1]" is now listening on 127.0.0.1:57002 for protocols iiops, t3s, ldaps, https.>
<Mar 11, 2013 5:18:27 AM CDT> <Notice> <WebLogicServer> <BEA-000329> <Started
WebLogic Admin Server "AdminServer" for domain "APPDomain" running in Production
Mode>
<Mar 11, 2013 5:18:27 AM CDT> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to RUNNING>
<Mar 11, 2013 5:18:27 AM CDT> <Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode>

Configuring WebLogic Scripts if Administration Server is Secured

WebLogic startup/shutdown scripts should be updated with secured port and protocol to start/stop services.

Backup and update following files in <DOMAIN_HOME>/bin with correct Admin server URLs.

Update the following files:

startManagedWebLogic.sh: echo "$1 managedserver1 http://[SERVERNAME].us.oracle.com:7001" stopManagedWebLogic.sh: echo "ADMIN_URL defaults to
t3://[SERVERNAME].us.oracle.com:7001 if not set as an environment variable or the
second command-line parameter."
stopManagedWebLogic.sh: echo "$1 managedserver1 t3://[SERVERNAME].us.oracle.com:7001 weblogic weblogic"
stopManagedWebLogic.sh: ADMIN_URL="t3://[SERVERNAME].us.oracle.com:7001"
stopWebLogic.sh: ADMIN_URL="t3://[SERVERNAME].us.oracle.com:7001"

Change the URLs to the values below wherever applicable.

t3s://[SERVERNAME].us.oracle.com:7102 https://[SERVERNAME].us.oracle.com:7102

Adding a Certificate to the JDK Keystore

Retail application installer will need Java to run. In situation where Administration server is secured using signed certificate, the Java keystore through which the installer is launched must have the certificate installed.

Example:

[SERVERNAME]:[10.3.6_apps] /u00/webadmin/ssl> keytool -import -trustcacerts -alias [SERVERNAME] -file /u00/webadmin/ssl/[SERVERNAME].cer -keystore
/u00/webadmin/product/jdk/jre/lib/security/cacerts
Enter keystore password: 
Certificate was added to keystore [SERVERNAME]:[10.3.6_apps] /u00/webadmin/ssl>

Enforcing Stronger Encryption in WebLogic

Upgrading JDK to use Java Cryptography Extension

If you want to use the strongest Cipher suite (256 bit encryption) you have to install the unlimited encryption JCE policy. It is dependent on the JDK version.

Using the following URL, download and install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files that correspond to the version of your JDK.

http://www.oracle.com/technetwork/java/javase/downloads/index.html

For JDK 8, download from http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html and replace the files in JDK/jre/lib/security directory.

Note:

Once the JCE has been installed, restart entire WebLogic instance using the JDK to enable changes to take effect.

Securing Nodemanager with SSL Certificates

Navigate to <DOMAIN_HOME>/nodemanager and take a backup of nodemanager.properties.

Add similar entry to nodemanager.properties:

KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=/u00/webadmin/ssl/[SERVERNAME].keystore CustomIdentityKeyStorePassPhrase=[password to keystore, this will get encrypted]
CustomIdentityAlias=[SERVERNAME]
CustomIdentityPrivateKeyPassPhrase=[password to keystore, this will get encrypted] CustomTrustKeyStoreFileName=/u00/webadmin/ssl/[SERVERNAME].keystore SecureListener=true

Login to WebLogic console, navigate to Environment > Machines. Select the nodemanager created already and navigate to Node Manager tab. In the Change Center, click Lock and Edit.
For Type, select SSL and save and activate (this may already be set to SSL).
"Listen Address" must be set to the server name used for the certificate request.

Figure 1-4 Nodemanager Window
After activating the changes, you need to bounce entire Weblogic Domain for changes to take effect. Verify the nodemanager is reachable in Monitoring tab after restart.

Advanced Infrastructure Security

Depending upon your security need for your production environment, infrastructure where retail applications are deployed can be secured. Following should be secured to ensure complete protection of environment.

Securing the WebLogic Server Host
Securing Network Connections
Securing Your Database
Securing the WebLogic Security Service
Securing Applications

Please refer to Ensuring the Security of Your Production Environment section in the Oracle® Fusion Middleware Securing a Production Environment for Oracle WebLogic Server 12c (12.2.1) for more information.

Troubleshooting

Java 8 SSL handshake issue while using self signed certificates

Java 8 may have issues using self signed certificates. The self-signed root certificate may not be recognized by Java 1.8 and a certificate validation exception might be thrown during the SSL handshake. To fix this problem, the private key must be created with Subject Key Identifier. An option "-addext_ski" must be included when the orapki utility is used to create the private key in the root wallet.

Import the root certificate in local client JRE

If customers are using certificates other than provided by standard certificate authorities like custom CA implementation, then the jre used for launching the applications from local machines like laptops or desktops might error with different error messages.

The most probable cause of this issue could be unavailability of root certificates of the CA within the local jre being used. In order to import the root certificates, follow the steps similar to below.

Backup cacert at <JRE_HOME>/lib/security/cacert.

Figure 1-5 Backup the CA Certificate

Import the certificate using the keytool utility.

C:\Program Files\Java\jre7\lib\security>..\..\bin\keytool.exe -import
-trustcacerts -file D:\ADMINISTRATION\SSL\[SERVERNAME]\Selfsigned\[SERVERNAME].root.cer
-alias [SERVERNAME] -keystore "C:\Program Files\Java\jre7\lib\security\cacerts"
 
Enter keystore password: [default is changeit]
Owner: CN=[SERVERNAME].us.oracle.com, OU=RGBU, O=Oracle Corporation, L=Minneapolis, ST=Minnesota, C=US
Issuer: CN=[SERVERNAME].us.oracle.com, OU=RGBU, O=Oracle Corporation, L=Minneapolis,
ST=Minnesota, C=US Serial number: 515d4bfb
Valid from: Thu Apr 04 15:16:35 IST 2013 until: Fri Apr 04 15:16:35 IST 2014
Certificate fingerprints:
MD5: AB:FA:18:2B:BC:FF:1B:67:E7:69:07:2B:DB:E4:C6:D9
SHA1: 2E:98:D4:4B:E0:E7:B6:73:55:4E:5A:BE:C1:9F:EA:9B:71:18:60:BB SHA256: F3:54:FB:67:80:10:BA:9C:3F:AB:48:0B:27:83:58:BB:3D:22:C5:27:7D: F4:D1:85:C4:4E:87:57:72:2B:6F:27
Signature algorithm name: SHA1withRSA
Version: 3
Trust this certificate? [no]: yes Certificate was added to keystore C:\Program Files\Java\jre7\lib\security>

Import the Root Certificate to the Browser

If the Root Certificate that signed WebLogic server certificate is not in that list of trusted CAs, you need to add it in the browser to avoid certificate verification error.

For Internet Explorer, that requires the following steps:

Copy the Root Certificate file to the workstation.
Rename the file to fa_root_cert.cer (this is a quick and easy way to associate the file with the Windows certificate import utility).

Figure 1-6 Rename Root Certificate
Double-click on the file.
Click Install Certificate and click Next.
Select Place all certificates in the following store and click Browse.
Select Trusted Root Certification Authorities and click OK.
Click Next.
Click Finish and then Yes at the Security Warning prompt.
Click OK to close the remaining open dialog boxes.

To do the same thing in Firefox, you follow a similar set of steps:

Start Firefox.
Select Tools > Options from the main menu.
Click on Advanced and then the Encryption tab.
On the Encryption tab, click View Certificates.
In Certificate Manager, click the Authorities tab and then the Import button.
In the Downloading Certificate dialog, choose Trust this CA to identify websites and click OK.
Click OK in Certificate Manager and then in Options.
Open a browser and test you URL using the SSL port.

Figure 1-7 Test the Firefox URL

Disabling Hostname Verification

The hostname verification ensures that the hostname in the URL to which the client connects matches the hostname in the digital certificate that the server sends back as part of the SSL connection. However, in case SSL handshake is failing due to inability to verify hostname this workaround can be used.

Note:

Disabling hostname verification is not recommended on production environments. This is only recommended for testing purposes. Hostname verification helps to prevent man-in-the-middle attacks.

To disable hostname verification for testing purposes, follow these steps:

Go to Environment -> Domain -> Servers -> AdminServer.
Click the SSL tab.
Click Advanced.
On Hostname Verification, select NONE.
Click Save and activate changes.

On the Node Manager startup script, look for JAVA. Add the following line:

Dweblogic.nodemanager.sslHostNameVerificationEnabled=false 
After this change, the script should look like this:
JAVA_OPTIONS="-Dweblogic.nodemanager.sslHostNameVerificationEnabled=false ${JAVA_OPTIONS}"
cd "${NODEMGR_HOME}"
set -x
if [ "$LISTEN_PORT" != "" ]
 then
   if [ "$LISTEN_ADDRESS" != "" ]

Restart Node manager.

Verifying Certificate Content

In situations where the certificate gets expired or may belong to other hosts, the certificates become unusable. To determine the details of the certificate keytool utility can be used. If the certificates are expired, they should be renewed or new certificates should be obtained from appropriate certificate authorities.

Example:

[SERVERNAME]:[10.3.6_apps] /u00/webadmin/ssl> keytool -printcert -file cert.cer
Certificate[1]:
Owner: CN=[SERVERNAME].us.oracle.com, OU=FOR TESTING PURPOSES ONLY, O=Oracle Corporation, L=Redwood City, ST=California, C=US
Issuer: CN=Oracle SSL CA, OU=Class 3 MPKI Secure Server CA, OU=VeriSign Trust Network, O=Oracle Corporation, C=US
Serial number: 8878deb9f2a1a44e3cd6d92a3987296
Valid from: Thu Oct 11 20:00:00 EDT 2012 until: Sat Oct 12 19:59:59 EDT 2013
Certificate fingerprints:
         MD5:  2B:71:89:11:01:40:43:FC:6F:D7:FB:24:EB:11:A5:1C
         SHA1: DA:EF:EC:1F:85:A9:DA:0E:E1:1B:50:A6:8B:A8:8A:BA:62:69:35:C1
         SHA256: C6:6F:6B:A7:C5:2C:9C:3C:40:E3:40:9A:67:18:B9:DC:8A:97:52:DB:FD:AB:4B:E5:B2:56:47:EC:A7:16:DF:B6
         Signature algorithm name: SHA1withRSA
         Version: 3
 
Extensions:

Verifying Keystore Content

Keystores are repository of the certificates. In situations when we are facing issues related to SSL Certificates, once can check the certificates which are available in the keystore. In case the certificates are not missing, they should be imported. keytool command provides the list of the certificates available.

Example:

$ keytool -v -list -keystore /u00/webadmin/product/jdk/jre/lib/security/cacerts
$ keytool -v -list -keystore /u00/webadmin/product/10.3.X_APPS/WLS/wlserver_10.3/server/lib/[SERVERNAME].keystore

Integration Issues

Retail applications can be deployed across different hosts and even behind network behind firewalls. Ensure that firewalls are configured to allow tcps connections to enable secure communications among integrated application.

Secured applications using signed certificates need to use same secured protocols for communication. Ensure that all the communicating applications use the same protocol. Refer to Enforcing stronger encryption in WebLogic section in Pre-install steps for Secured setup of Retail Infrastructure in WebLogic chapter on steps to specify secured protocol.

Communicating applications using signed certificates may need to verify the incoming connections. Root certificates should be available in the keystores of the applications to verify the requests from different host. It is important to import all the root certificates in the keystores of all communicating applications. Refer to Import the root certificate in local client JRE section in Troubleshooting chapter for steps to import root certificates.

Technical Overview of the Security Features

Retail Insights Security Features

Authentication is required when Retail Insights end users run Retail Insights front-end report or Retail Insights batch users execute Retail Insights batch in the back-end. For front-end, the authentication, including the storage of the credential of database connection, is managed by Oracle OAS, WebLogic, and Oracle IDCS or OCI IAM. For the back-end, the authentication, including the storage of the credentials of the database connection, is managed by ODI and Oracle DB Wallet.
During Retail Insights installation, it is required to create different Retail Insights database users with different permissions. Within these database users, the Retail Insights data mart user is the user who owns data. The Retail Insights batch user is the user who executes Retail Insights batch. The batch user is granted with SELECT, UPDATE/INSERT, and DELETE permissions to the resources owned by the Retail Insights data user. The Retail Insights front-end user is the database user who will query Retail Insights data through the front-end report. This user is granted with SELECT permission to the resources owned by the Retail Insights data user.
The Universal Adapter is an optional ETL component which facilitates the loading of flat files generated from source system into Retail Insights database staging tables. The Universal Adapter is dependent on the Oracle Client installed on the Application server, so a sqlldr utility can be used to load data from files to RI staging tables. The credentials used in the sqlldr are stored in the Oracle Wallet.
The Aggregation Framework is an optional ETL component which facilitates the loading of aggregation data into client customized aggregation tables. The Aggregation Framework is PL/SQL based programs. It requires that the Retail Insights batch user be granted read+write access to the UTLFILE folder on the database server. The framework can be uninstalled from the batch schema by dropping procedures RA_AGGREGATION_DAILY and RA_AGGREGATION_REC.