Skip Headers
Oracle® Health Sciences Clinical Development Analytics Security Guide
Release 3.1.1

E63314-01
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

  PDF · Mobi · ePub

Oracle® Health Sciences Clinical Development Analytics

Security Guide

Release 3.1.1

E63314-01

May 2015

This document provides the security guidelines that must be followed to use the Oracle Health Sciences Clinical Development Analytics (OHSCDA) application. It includes the following sections:

1 General Security Principles

The following principles are fundamental to using any application securely.

1.1 Keeping Software Up To Date

One of the principles of good security practice is to keep all software versions and patches up to date.

1.2 Keeping Up To Date on Latest Security Information Critical Patch Updates

Oracle continually improves its software and documentation. Critical Patch Updates are the primary means of releasing security fixes for Oracle products to customers with valid support contracts. They are released on the Tuesday closest to the 17th day of January, April, July and October. We highly recommend customers apply these patches as soon as they are released.

1.3 Configuring Strong Passwords on the Database

Although the importance of passwords is well known, the following basic rule of security management is worth repeating:

Ensure all passwords are strong passwords.

You can strengthen passwords by creating and using password policies for your organization. For guidelines on securing passwords and for additional ways to protect passwords, refer to the Oracle® WebLogic Portal Security Guide specific to the database release you are using.

You should modify the following passwords to use your policy-compliant strings:

  • Passwords for the database default accounts, such as SYS and SYSTEM.

  • Passwords for the database application-specific schema accounts, such as RXI.

  • The password for the database listener. Oracle recommends that you do not configure a password for the database listener as that will enable remote administration. For more information, refer to Oracle® Database Net Services Reference 11g Release 2 (11.2).

1.4 Following the Principle of Least Privilege

The principle of least privilege states that users should be given the least amount of privilege to perform their jobs. Overly ambitious granting of responsibilities, roles, grants — especially early on in an organization's life cycle when people are few and work needs to be done quickly — often leaves a system wide open for abuse. User privileges should be reviewed periodically to determine relevance to current job responsibilities.

1.5 Managing Default User Accounts

Lock and expire default user accounts.

1.6 Closing All Open Ports Not in Use

Keep only the minimum number of ports open. You should close all ports not in use.

1.7 Disabling the Telnet Service

Oracle Health Sciences Clinical Development Analytics Standard Configuration does not use the Telnet service.

Telnet listens on port 23 by default.

If the Telnet service is available on any computer, Oracle recommends that you disable Telnet in favor of Secure Shell (SSH). Telnet, which sends clear-text passwords and user names through a log-in, is a security risk to your servers. Disabling Telnet tightens and protects your system security.

1.8 Disabling Other Unused Services

In addition to not using Telnet, the Oracle Health Sciences Clinical Development Analytics Standard Configuration does not use the following services or information for any functionality:

  • Simple Mail Transfer Protocol (SMTP): This protocol is an Internet standard for E-mail transmission across Internet Protocol (IP) networks.

  • Identification Protocol (identd): This protocol is generally used to identify the owner of a TCP connection on UNIX.

  • Simple Network Management Protocol (SNMP): This protocol is a method for managing and reporting information about different systems.

Restricting these services or information does not affect the use of Oracle Health Sciences Clinical Development Analytics Standard Configuration. If you are not using these services for other applications, Oracle recommends that you disable these services to minimize your security exposure. If you need SMTP, identd, or SNMP for other applications, be sure to upgrade to the latest version of the protocol to provide the most up-to-date security for your system.

1.9 Designing for Multiple Layers of Protection

When designing a secure deployment, design multiple layers of protection. If a hacker should gain access to one layer, such as the application server, that should not automatically give them easy access to other layers, such as the database server.

Providing multiple layers of protection may include:

  • Enable only those ports required for communication between different tiers, for example, only allowing communication to the database tier on the port used for SQL*NET communications (1521 by default).

  • Place firewalls between servers so that only expected traffic can move between servers.

1.10 Enabling SSL

Due to the complexity in setting up SSL, it is not enabled by default during installation. Communications between the browser and the application servers should be restricted to SSL. See the Oracle WebLogic Server 11g guidelines for instructions on enabling SSL.

You must start the Oracle WebLogic Server with a parameter to exclude SSL 2.0 and/or SSL 3.0 to in order to mitigate the SSL V3.0 "Poodle" Vulnerability, CVE-2014-3566. For more information, see How to Change SSL Protocols (to Disable SSL 3.0) in Oracle Fusion Middleware Products (Doc ID 1936300.1) on My Oracle Support (https://support.oracle.com)

2 Protected Health Information

OHSCDA contains the following subject data that are used for both out of the box reports and/or available for use in ad hoc queries:

  • Date of Birth

  • Initials

  • Subject ID (concatenation of initials and date of birth)

  • Screening # (concatenation of initials and date of birth)

If you have concerns over these data, you have several options available. You can configure the source systems to not use initials and data of birth in Subject ID and Screening # measures. Additionally, you can remove the Data of Birth and Initials measures from the presentation in OHSCDA as these are not used in any out of the box reports.

2.1 Removing PHI Measures

You can configure the OHSCDA repository to remove measures that contain PHI data. Refer to OBIEE documentation for full instructions on configuring the RPD.

  1. Open the RPD in the OBIEE Administration tool.

  2. Delete the following measures from the Subject folder in the presentation layer:

    • Date of Birth

    • Initials

    • Subject ID (concatenation of initials and date of birth)

    • Screening # (concatenation of initials and date of birth)

  3. Deploy the updated RPD on the OBIEE server.

2.2 Exporting Data

OHSCDA out of the box utilizes native OBIEE export functionality. You can export any report into PDF, Excel, Powerpoint, web archive (.mht), csv, tab delimited, or xml.

If you have concerns over exporting data, you have several options available. You can modify the dashboard properties and remove the export link at the bottom of reports. You can also enable the OBIEE's Usage Tracking option. This option tracks which queries were run by which users and when.

3 Security Guidelines for Oracle Business Intelligence Enterprise Edition

While installing and configuring the OBIEE Server, you should follow guidelines in the document Oracle® Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1)Part Number E10543-02.

3.1 Checking External Links that May Expose Account Data

It is possible to add customized links to web applications that are deployed in a web server. Through this mechanism, any information that can be made available through a URL can be made accessible to OHSCDA users. In addition, your customized links may support passing session parameters, such as the log-in user ID, and currently selected Product, Program, Study and Site to a URL. By passing these session parameters, you can access Web pages specific to you current selections on these attributes. However, you should be aware that in links that access external Web sites, passing account data and session information may pose a security risk.

3.2 Managing Usage Tracking

For information, see Oracle® Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

4 Setting up Transparent Data Encryption Tablespace

To set up the transparent data encryption tablespace, perform the following configuration steps:

  1. Create a wallet by executing the following syntax at the command line.

    mkstore -wrl <wallet_location> -create
    

    Note:

    <wallet_location> is the directory where you want to create and store the wallet.

    The command will prompt for the wallet password twice. Enter the same password and note down the password as it will used later.

  2. Update the sqlnet.ora file.

    1. Navigate to $ORACLE_HOME\NETWORK\ADMIN.

    2. Update the sqlnet.ora file for ENCRYPTION_WALLET_LOCATION.

      For example,

      ENCRYPTION_WALLET_LOCATION=                        (SOURCE=(METHOD=FILE)(METHOD_DATA=                                  (DIRECTORY=<wallet location>)))
      
  3. Create a wallet key and open the wallet in the database.

    ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "<password>";
    

    Note:

    You must enter the same password used in step 1.
  4. Create an encrypted tablespace. Run the following command:

    CREATE TABLESPACE <tablespace name>DATAFILE '<data file location>' SIZE 500M AUTOEXTEND ON NEXT 1m ENCRYPTION USING 'AES256' DEFAULT STORAGE (ENCRYPT);
    
  5. Create a schema and grant access to the encrypted tablespace.

    To create user or schema, run the following command:

    Create user <username> identified by <user_password>;
    

    To grant user access, execute the following command:

    Grant connect, resource to <username>;
    

    To grant tablespace quota, execute the following command.

    ALTER USER <username> QUOTA UNLIMITED ON <tablespace name>;
    

5 Configuring SSO for OHSCDA OBIEE Using Oracle Access Manager 11g

This section describes the steps to configure SSO in Oracle Access Manager (OAM) 11g.

5.1 Prerequisites

The following are the prerequisites:

  • OAM 11g installation must be configured to work with the desired LDAP.

    (For example, OUD), as the identity data-store.

  • User profiles must exist in the LDAP server as well as in the Argus Safety with the same credentials.

  • Oracle Web Tier 11.1.1.3 (or higher) must be installed on the same server where the OBIEE server is installed and configured with the WebLogic Server hosting OBIEE.

  • Oracle Webgate 11g must be installed on the same server where the OBIEE server is installed.

5.2 Installing SSO on OAM 11g

To install SSO on OAM 11g, perform the following steps:

  1. Navigate to the OAM 11g OAM Console URL (http://oam_server:port/oamconsole) and log in with the OAM Admin credentials.

  2. Select the System Configuration tab.

  3. Select the Access Manager Settings submenu in the left navigation window of the browser.

  4. Double-click SSO Agents and select the OAM Agents option to open the OAM Agents sub window.

  5. Click Create 11g Webgate and enter the following details:

    • Specify the name for the OHSCDA Policy.

    • In the Security field, select the Open option.

    • Enter the host identifier. For example, <obiee_server>.

      Note:

      The <obiee_server> refers to the server where the OBIEE 11g is installed along with Oracle Web Tier and Oracle Webgate.
    • Select the Auto Create Policies option.

  6. Click Apply to save and register the 11g Webgate and policies with OAM.

  7. On the subsequent page, update the details for the OHSCDA policy created in step 5.

    • Cache Pragma Header: Private

    • Cache Control Header: Private

  8. Click Apply.

  9. Navigate to the Policy Configuration tab.

  10. Expand and double-click Shared Components > Resource Type > Host Identifiers > <obiee_server> (for example, server.domain.com) to open the Host Identifiers window and add the following details:

    • <obiee_server>

    • <obiee_server> <port>

    • <obiee_server_ip>

    • <obiee_server_ip> <port>

      Note:

      <obiee_server> refers to the server where the OBIEE 11g is installed along with Oracle Web Tier and Oracle Webgate. The port refers to the Oracle Web Tier Port.
  11. Expand and double-click Application Domains > <OHSCDA Policy> > Authentication Policies > Protected Resource Policy.

  12. Ensure that the Authentication Scheme is set as LDAPScheme.

  13. Ensure that the following resources are present:

    • /

    • /…/*

  14. Add the following response variables:

    • Name: OAM_REMOTE_USER

    • Type: Header

    • Value: $user.attr.uid [based on the LDAP schema setup]

  15. Click Apply and save the changes.

  16. Expand and double-click Application Domains > <OHSCDA Policy> > Authorization Policies > Protected Resource Policy

  17. Ensure that the following resources are present:

    • /

    • /…/*

  18. Add the following response variables:

    • Name: OAM_REMOTE_USER

    • Type: Header

    • Value: $user.attr.uid [based on the LDAP schema setup]

  19. Click Apply to save the changes.

  20. Navigate to the OHSCDA Web Tier Machine [<obiee_server>], where the OHSCDA OBIEE server is installed.

  21. Run the installer for Webgate (OFM Webgate 11g for OAM 11g) to complete the installation.

  22. Configure the 11g Webgate using the following steps to communicate with the OAM 11g server:

    Note:

    For more information, see Oracle® Fusion Middleware Installation Guide for Oracle Identity Management11g Release 1 (11.1.1).
    1. Move to the following directory under your Oracle Home for Webgate:

      On UNIX Operating Systems:

      <Webgate_Home>/webgate/ohs/tools/deployWebGate

      On Windows Operating Systems:

      <Webgate_Home>\webgate\ohs\tools\deployWebGate

    2. On the command line, run the following command to copy the required bits of agent from the Webgate_Home directory to the Webgate Instance location:

      On UNIX Operating Systems:

      ./deployWebgateInstance.sh -w <Webgate_Instance_Directory> -oh <Webgate_Oracle_Home>

      On Windows Operating Systems:

      deployWebgateInstance.bat -w <Webgate_Instance_Directory> -oh <Webgate_Oracle_Home>

      where, <Webgate_Oracle_Home> is the directory where you have installed Oracle HTTP Server Webgate and created as the Oracle Home for Webgate, as shown in the following example:

      MW_HOME>/Oracle_OAMWebGate1

      The <Webgate_Instance_Directory> is the location of Webgate instance home, which is the same as the instance home of Oracle HTTP Server, as shown in the following example:

      <MW_HOME>/Oracle_WT1/instances/instance2/config/OHS/ohs1

    3. Run the following command to ensure that the LD_LIBRARY_PATH variable contains <Oracle_Home_for_Oracle_HTTP_Server>/lib:

      On UNIX (depending on the shell):

      export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<Oracle_Home_for_Oracle_HTTP_Server>/lib

      On Windows:

      Set the <Webgate_Installation_Directory>\webgate\ohs\lib location and the <Oracle_Home_for_Oracle_HTTP_Server>\bin location in the PATH environment variable.

      Add a semicolon (;) followed by this path at the end of the entry for the PATH environment variable.

    4. From your current working directory, move up one directory level:

      On UNIX Operating Systems, move to:

      <Webgate_Home>/webgate/ohs/tools/setup/InstallTools

      On Windows Operating Systems, move to:

      <Webgate_Home>\webgate\ohs\tools\EditHttpConf

    5. On the command line, run the following command to copy the apache_webgate.template from the Webgate_Home directory to the Webgate instance location (renamed to webgate.conf) and update the httpd.conf file to add one line to include the name of webgate.conf:

      On UNIX operating systems:

      ./EditHttpConf -w <Webgate_Instance_Directory> -oh <Webgate_Oracle_Home> -o <output_file>

      On Windows operating systems:

      EditHttpConf.exe -w <Webgate_Instance_Directory> -oh <Webgate_Oracle_Home> -o <output_file>

      where, <Webgate_Oracle_Home> is the directory where Oracle HTTP Server Webgate is installed for Oracle Access Manager and created as the Oracle Home for Webgate, as shown in the following example:

      <MW_HOME>/Oracle_OAMWebGate1

      The <Webgate_Instance_Directory> is the location of Webgate instance home, which is the same as the instance home of Oracle HTTP Server, as shown in the following example:

      <MW_HOME>/Oracle_WT1/instances/instance2/config/OHS/ohs1

      The <output_file> is the name of the temporary output file used by the tool, as shown in the following example:

      Edithttpconf.log

    6. Copy Generated Files (Artifacts) to the Webgate Instance Location from the OAM 11g server.

      The 11g Webgate Agent (<OHSCDA Policy>), which was created in the OAM 11g OAM Console, would have also created the following artifacts on the OAM 11g server:

      - cwallet.sso

      - ObAccessClient.xml

      This is based on the Security Mode that you have configured, which in this case is Open.

      On the OAM 11g server, these files are present at the following location:

      <OAM_FMW_HOME>/user_projects/domains/<OAM_domain>/output/<OHSCDA Policy>

  23. Copy these files to the <obiee_server> in the following directory:

    <Webgate_Instance_Directory>/webgate/config directory

    For example, <MW_HOME>/Oracle_WT1/instances/instance2/config/OHS/ohs1/webgate/config.

  24. Restart the Oracle HTTP Server instance.

    To stop the Oracle HTTP Server instance, run the following commands on the command line:

    <MW_HOME>/Oracle_WT1/instances/instance2/bin/opmnctl stopall

    To restart the Oracle HTTP Server instance, run the following commands on the command line:

    <MW_HOME>/Oracle_WT1/instances/instance2/bin/opmnctl startall

  25. Configure the HTTP Server as a reverse proxy for the WebLogic Server. To execute this, modify the mod_wl_ohs.conf file present at the following location:

    OracleWebTierHome\instances\instance2\config\OHS\ohs1

    The following is a template to configure mod_weblogic:

    LoadModule weblogic_module "${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so"

    # This empty block is needed to save mod_wl related configuration from EM to this file when changes are made at the base virtual host level:

    <IfModule weblogic_module>
    # WebLogicHost <WEBLOGIC_HOST>
    # WebLogicPort <WEBLOGIC_PORT>
    # Debug ON
    # WLLogFile /tmp/weblogic.log
    # MatchExpression *.jsp
     
    <Location /console>
    SetHandler weblogic-handler
    WebLogicHost <WebLogic host name>
    WeblogicPort <WebLogic port number
    WLProxySSL ON
    WLProxySSLPassThrough ON
    </Location>
     
    <Location /em>
    SetHandler weblogic-handler
    WebLogicHost <WebLogic host name>
    WeblogicPort <WebLogic port number
    WLProxySSL ON
    WLProxySSLPassThrough ON
    </Location>
     
    <Location /analytics>
    SetHandler weblogic-handler
    WebLogicHost <WebLogic host name>
    WeblogicPort <OBIEE Analytics Port>
    WLProxySSL ON
    WLProxySSLPassThrough ON
    </Location>
     
    <Location /analyticsRes>
    SetHandler weblogic-handler
    WebLogicHost <WebLogic host name>
    WeblogicPort <OBIEE Analytics Port>
    WLProxySSL ON
    WLProxySSLPassThrough ON
    </Location>
     
    <Location /xmlpserver>
    SetHandler weblogic-handler
    WebLogicHost <WebLogic host name>
    WeblogicPort <OBIEE Analytics Port>
    WLProxySSL ON
    WLProxySSLPassThrough ON
    </Location>
     
    </IfModule>
    # <Location /weblogic>
    # SetHandler weblogic-handler
    # PathTrim /weblogic
    # ErrorPage http:/WEBLOGIC_HOME:WEBLOGIC_PORT/
    # </Location>
    
  26. Restart the Web Tier Instance in WebLogic EM or as described in step 23.

  27. Configure a new authenticator for Oracle WebLogic Server on the OBIEE server using the following steps:

    1. Login to the WebLogic Server Administrator Console and navigate to Security Realms > myrealm.

    2. Click the Providers tab.

    3. Click Lock & Edit on the right corner of the webpage, highlighted as Change Center.

    4. Click New to create a new authentication provider and add the following details:

      Name: A name of your choice <Name>

      Type: OracleInternetDirectoryAuthenticator

    5. After saving the details, click the new authenticator that you have created, and enter the following details:

      In the sub tab, change the Control Flag as SUFFICIENT

    6. Click Save.

    7. Click the Provider Specific tab and enter the following settings required using values for your environment:

      - Host: Your LDAP host.

      - Port: Your LDAP host listening port.

      - Principal: LDAP administrative user.

      For example, cn=Directory Manager

      - Credential: LDAP administrative user password.

      - User Base DN: Same search base as in Oracle Access Manager.

      For example, dc=us, dc=oracle, dc=com

      - All Users Filter:

      For example, (&(uid=*) (objectclass=person))

      - User Name Attribute: Set as the default attribute for username in the directory server.

      For example, uid

      - Group Base DN: The group search base.

      For example: dc=us, dc=oracle, dc=com

      - All Groups Filter:

      For example, (&(cn=*)(|(objectclass=groupofUniqueNames)(objectclass=groupOfURLs)))

      - Group From Name Filter:

      For example, (|(&(cn=%g)(objectclass=groupofUniqueNames))(&(cn=%g)(objectclass=groupOfURLs)))

      - Static Group Name Attribute:

      For example, cn

      - Static Group Object Class:

      For example, groupofuniquenames

      - Static Member DN Attribute:

      For example, uniquemember

      - Static Group DNs from Member DN Filter:

      For example, (&(uniquemember=%M)(objectclass=groupofuniquenames))

      - Dynamic Group Name Attribute:

      For example, cn

      - Dynamic Group Object Class:

      For example, groupOfURLs

      - User Dynamic Group DN Attribute:

      For example, uniquemember

      - Leave the other defaults as is.

      - GUID Attribute: The GUID attribute defined in the OUD LDAP Server

      For example, uid

    8. Click Save.

  28. Configure a new Identity Asserter for WebLogic Server using the following steps:

    1. In the Oracle WebLogic Server Administration Console, select Security Realms from the left pane and click the realm which you want to configure.

      For example, myrealm.

    2. Select Providers.

    3. Click New and enter the following values in the fields:

      Name: <Name>OAMIdentityAsserter or a name of your choice

      Type: OAMIdentityAsserter

    4. Click OK.

    5. Click on the newly created asserter and set the Control Flag to REQUIRED.

    6. Ensure that the Active Types that you have selected is OAM_REMOTE_USER.

    7. Click Save.

    8. Navigate to the Provider Specific tab and enter the following details:

      - Transport Security: open

      - Application Domain: <Name>, as set in the OAM 11g Console

      - Access Gate Name: <Name>, as specified in the OAM 11g Console

      - Primary Access Server: <Name>:<Port>, OAM 11g server with port

    9. Click Save.

    10. In the Providers tab, perform the following steps to reorder providers:

      i. Click Reorder.

      ii. On the Reorder Authentication Providers page, select a provider name and use the arrows to order the following providers:

      - <Name>OAMIdentityAsserter

      - OCDAAuthenticator

      - DefaultAuthenticator

      - DefaultIdentityAsserter

      iii. Click OK to save your changes.

    11. In the Providers tab, click Default Authenticator and change the Control Flag to Sufficient.

    12. In the Change Center, click Activate Changes.

    13. Restart Oracle WebLogic Server

  29. Delete the BISystemUser present in the default embedded LDAP (using Security Realms in the Administration Console Link of the WebLogic Server) and add the same or another user in the newly added OID.

    You must add this user to the BI Application Roles using the following steps:

    1. Navigate to Administration Console > Security Realms > myrealm > Users and Groups > Users and select the BISystemUser check box (from Provider: Default Authenticator).

    2. Click Delete.

    3. Navigate to Security Realms > myrealm > Roles and Policies > Realm Roles.

    4. In the tree structure, expand Global Roles node and select the Roles link.

    5. In the subsequent screen, click the Admin Role link.

    6. Click Add Conditions.

    7. In the next screen, select the Predicate List as User and click Next.

    8. In the User Argument Name, enter BISystemUser and click ADD.

    9. Click Finish.

    10. In the Role Conditions screen, ensure that the set operator is set to Or.

    11. Save the configuration.

    12. Navigate to the Enterprise Manager of OBIEE or the Fusion Middleware Control page and navigate in the tree structure to the Business Intelligence > coreapplication node.

    13. In the Business Intelligence drop-down menu, select Security > Application > Roles.

    14. In the Roles displayed, select BISystem, and in the next screen remove the old BISystemUser (from the Default Provider), and add the newly created BISystemUser user in OUD.

    15. Add the trusted user's credentials to the oracle.bi.system credential map.

    16. Using Fusion Middleware Control target navigation pane, navigate to farm > WebLogic Domain, and select bifoundation_domain.

      i. Using the WebLogic Domain menu, select Security > Credentials.

      ii. Open the oracle.bi.system credential map, and select system.user.

      iii. Click Edit.

      iv. In the Edit Key dialog box, enter BISystemUser (or a name of your choice) in the User Name field.

      v. In the Password field, enter the trusted user's password that is contained in Oracle Internet Directory.

      vi. Click OK.

    17. Restart the Managed Servers.

  30. Enable the SSO authentication in the Weblogic Server for OBIEE using the following steps:

    1. Login to Fusion Middleware Control (EM) of the WebLogic Server.

    2. Navigate to the Business Intelligence Overview page.

    3. Navigate to the Security page.

    4. Click Lock and Edit Configuration.

    5. Select Enable SSO, this makes the SSO provider list active.

    6. Select the configured SSO provider from the list, as Oracle Access Manager.

    7. In The SSO Provider Logoff URL, specify the following URL:

      http://<oam_server>:14100/oam/server/logout

    8. Click Apply.

    9. Click Activate Changes.

    10. Restart the Oracle Business Intelligence components using Fusion Middleware Control.

6 Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.


Oracle Health Sciences Clinical Development Analytics Security Guide, Release 3.1.1

E63314-01

Copyright © 2013, 2015 Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.