Skip Headers
Oracle® Fusion Middleware Configuration Guide for Oracle Business Intelligence Discoverer
11g Release 1 (11.1.1)

Part Number B40107-09
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

13 Maintaining Security with Oracle BI Discoverer

This chapter only applies to Discoverer Plus and Discoverer Viewer. For more information about configuring Discoverer Plus OLAP, see Chapter 5, "Configuring Discoverer Plus OLAP".

This chapter describes the different security mechanisms that Discoverer uses to protect sensitive resources, and contains the following topics:

13.1 About Discoverer and security

Discoverer uses (and must therefore protect) different sensitive resources, including:

The table below shows the sensitive resources used and protected by the different Discoverer components:

Sensitive resource Used and protected by Discoverer Plus Used and protected by Discoverer Viewer Used and protected by Discoverer Portlet Provider Used and protected by Discoverer Administrator Used and protected by Discoverer pages in Fusion Middleware Control

Data

Yes

Yes

Yes

Yes

Not used

Metadata

Yes

Yes

Yes

Yes

Yes

Discoverer connections

Yes

Yes

Yes

Not used

Yes

System resources

Yes

Yes

Yes

Yes

Yes

Network resources

Yes

Yes

Yes

Yes

Yes


Discoverer uses several security mechanisms to prevent unauthorized access to the above resources. These security mechanisms are provided by the following security models:

The diagram below shows the multiple security mechanisms employed by Discoverer, all of which ultimately protect data and system resources from unauthorized access:

Surrounding text describes secure1.gif.

The security mechanisms that Discoverer employs depend on the category of Discoverer user (as defined by the Discoverer product they are using), as follows:

The table below shows the security models are used by Discoverer components:

Security Model Used by Discoverer Plus Used by Discoverer Viewer Used by Discoverer Portlet Provider Used by Discoverer Administrator Used by Discoverer pages in Fusion Middleware Control

Database

Yes

Yes

Yes

Yes

No

Discoverer EUL

Yes

Yes

Yes

Yes

No

Applications

Yes

Yes

Yes

Yes

No

Oracle Fusion Middleware

Yes

Yes

Yes

No

Yes


13.2 About Discoverer and the database security model

At the most basic level, data in the database is protected from unauthorized access by the database's own security model. In the case of an Oracle database, this security model comprises:

The database privileges granted directly to database users (or granted indirectly through database roles) determine the data that users can access. Typically, you set up database security by using a database administration tool or SQL*Plus.

Discoverer uses the database's own security model to ensure that users never see information to which they do not have database access.

For more information about the database security model and how Discoverer uses it, see Oracle Fusion Middleware Administrator's Guide for Oracle Business Intelligence Discoverer.

Note: Discoverer is certified with the Oracle Advanced Security Option (ASO) encryption technology provided by the Oracle database (that is, in Oracle 8.1.7 databases and later). The certification has four encryption types (RC4, DES, Triple-DES, and AES). Oracle ASO encryption incurs little performance overhead, although performance varies depending on several factors (for example, the operating system, the encryption algorithm). For more information about Oracle ASO encryption, refer to the Oracle database documentation.

13.3 About Discoverer and the Discoverer EUL security model

Discoverer managers use Discoverer Administrator to grant Discoverer access permissions and task privileges directly to database users (or indirectly through database roles), as follows:

Regardless of the access permissions and task privileges granted in Discoverer Administrator, a Discoverer end user only sees folders if that user has been granted the following database privileges (either directly or through a database role):

Even if they share workbooks with each other, Discoverer users never see information to which they do not have database access.

Discoverer Administrator also enables Discoverer managers to protect system resources by:

Discoverer managers can extend Discoverer functionality by registering their own PL/SQL functions. However, they can only register PL/SQL functions to which they have been granted the EXECUTE database privilege.

For more information about the Discoverer EUL security model, see Oracle Fusion Middleware Administrator's Guide for Oracle Business Intelligence Discoverer.

Notes

13.4 About Discoverer and the Oracle Applications security model

A common use of Discoverer is to provide ad-hoc query access to Oracle Applications databases. To provide such access, Discoverer managers can use Discoverer Administrator to create Applications mode EULs.

Discoverer end users can connect to an Oracle Applications database using their Oracle e-Business Suite user ID and responsibility. For more information, see Section 14.1, "About Discoverer connections and Oracle e-Business Suite".

An Oracle Applications mode EUL is a Discoverer End User Layer based on an Oracle Applications schema (containing the Oracle Applications FND (Foundation) tables and views).

Oracle Applications EULs make use of the following Oracle Applications security model features:

Notes

13.5 About Discoverer and the Oracle Fusion Middleware Security model

Note: This section applies only if the Discoverer installation is associated with the Oracle Internet Directory and the Discoverer schemas. For more information, see Section 1.3, "About Oracle BI Discoverer installations."

Oracle Security is an integrated management and security framework that provides:

The Oracle Fusion Middleware Security model comprises:

To ensure that Discoverer fully leverages the Oracle Fusion Middleware Security model:

In addition, the Oracle Fusion Middleware Security model underpins the Discoverer connection mechanism (for more information, see Section 13.5.1, "About Discoverer public connections and the Oracle Fusion Middleware Security model").

For more information about Oracle Security, see:

13.5.1 About Discoverer public connections and the Oracle Fusion Middleware Security model

Discoverer managers can give users access to information by using Oracle Fusion Middleware Control to create public connections. Each connection specifies an EUL containing one or more business areas.

Discoverer managers can control users' access to information by restricting users to using public connections or by giving users permission to create their own private connections.

For more information about connections, see Chapter 3, "Managing Oracle BI Discoverer Connections".

13.6 Using Discoverer with Oracle Fusion Middleware Security

Oracle Fusion Middleware Security provides several services, including:

You can specify that Discoverer uses the HTTPS/SSL support offered by the Oracle HTTP Server as one of the communication protocols to communicate between the Discoverer server and the Discoverer client tier components. For more information, see:

For more information about Oracle Fusion Middleware Security, see Oracle Fusion Middleware Application Security Guide.

Notes

13.6.1 About specifying Discoverer communication protocols

You can use Discoverer in different network environments that might or might not include firewalls using different communication protocols (that is, JRMP, HTTP, HTTPS).

The most appropriate network environment depends on both existing network strategies in your organization and your requirements for:

  • performance (how long it takes to display information)

  • accessibility (whether data has to be accessed through a firewall)

  • security (how secure the data needs to be during transmission)

Note that you must use HTTPS if you want to ensure that sensitive information (for example, passwords, data) is securely transmitted across a network.

Discoverer Viewer and Discoverer Plus require different security configurations:

Notes

  • If you are deploying Oracle BI Discoverer with Oracle Web Cache, there are security implications for some restricted user environments.

    For more information, see:

  • If you have deployed Discoverer in a multiple-machine installation, note that you might want to specify different communication protocols on different Discoverer middle tier machines. For example, you might use:

    • the JRMP protocol on one machine for Plus users working inside a firewall

    • the HTTPS protocol on two other machines for Viewer users accessing reports across the Web

13.6.2 About Discoverer Viewer security and communication protocols

Discoverer Viewer uses standard HTTP or HTTPS protocols to connect Discoverer Viewer clients to the Discoverer servlet.

Surrounding text describes sec1.gif.

Note: Discoverer Viewer client machines require only a standard Web browser to run Discoverer Viewer.

In a default Oracle installation, Discoverer Viewer is configured as follows:

  • In an HTTP environment, no additional security configuration is required. If you are using a firewall, open the firewall for the Oracle HTTP Server port used by Oracle (for example, 80).

  • If you are using a firewall, open the firewall for the Oracle HTTP Server SSL port used by Oracle (for example, 4443). In an HTTPS environment, Discoverer Viewer uses SSL security certificates on the client machine's browser. If you are using a nonstandard or private SSL signing authority, you must install the root certificates in the browser. For more information about deploying Discoverer Viewer over HTTPS, see Section 2.5, "About running Discoverer over HTTPS").

13.6.3 About Discoverer Plus security and communication protocols

Discoverer Plus uses standard Java Remote Method Protocol (JRMP), HTTP, or HTTPS protocols to connect clients to the Discoverer servlet.

Surrounding text describes sec2.gif.

Discoverer Plus uses two communication channels:

  • when a Discoverer Plus client first connects to the Discoverer servlet, the Discoverer Plus applet is downloaded and installed on the Discoverer client machine

  • after the Discoverer Plus applet is installed on the Discoverer client machine, the Discoverer Plus client machine uses one of JRMP, HTTP, or HTTPS to communicate with the Discoverer servlet

In a default Oracle installation, Discoverer Plus is configured as follows, depending on the environment:

  • In an Intranet environment (that is, inside firewalls), no additional security configuration is required. Discoverer Plus clients connect to the Discoverer servlet using the JRMP protocol.

    Ensure that the default Discoverer Plus communication protocol (that is, Default) is selected (for more information, Section 13.6.3.3, "How to set up Discoverer Plus to use the Default communication protocol").

  • In an HTTPS environment, Discoverer Plus uses security certificates on the client machine's browser. When you run Discoverer Plus for the first time over HTTPS (that is, in Secure Sockets Layer (SSL) mode), you must install your Web server's security certificate into the Java Virtual Machine (JVM) certificate store in all client machines that must run Discoverer Plus.

    Note: To deploy Discoverer Plus over HTTPS, you must select the Secure Tunneling security protocol in Oracle Fusion Middleware Control (Section 13.6.3.5, "How to set up Discoverer Plus to use the Secure Tunneling communication protocol").

    For more information about deploying Discoverer Plus over HTTPS, see Section 2.5, "About running Discoverer over HTTPS").

    If you are using a firewall, open the firewall for the Oracle HTTP Server SSL port used by Oracle (for example, port 4443 on a UNIX middle tier or 443 on a Windows middle tier).

Notes

13.6.3.1 About specifying a Discoverer Plus communication protocol

Using Fusion Middleware Control, you can specify which communication protocol the Discoverer Plus applet (that is, the Discoverer client) and the Discoverer servlet (that is, on the Discoverer middle tier) use to communicate. The three communication protocol options are:

  • Default

    Specify this option if you want the Discoverer Plus applet to attempt to use JRMP and if this fails, to use HTTP or HTTPS (depending on the URL) to communicate with the Discoverer servlet.

    The advantage of using the Default communication protocol is that Discoverer Plus works regardless of whether the client browser is running inside or outside a firewall. However, it is slower outside the firewall on the initial connection because JRMP is tried first.

    For more information about specifying this option, see Section 13.6.3.3, "How to set up Discoverer Plus to use the Default communication protocol".

  • Tunneling

    Specify this option if you want the Discoverer Plus client to connect using the same method to communicate with the Discoverer servlet as was originally used to download the applet itself (that is, either HTTP or HTTPS depending on the URL). This option works regardless of whether a firewall is being used.

    The advantage of using the Tunneling communication protocol is that it is quicker than the Default option, because JRMP is not attempted first before failing and trying again using HTTP or HTTPS.

    For more information about specifying this option, see Section 13.6.3.4, "How to set up Discoverer Plus to use the Tunneling communication protocol".

  • Secure Tunneling

    Specify this option if you want the Discoverer Plus client to always use HTTPS to communicate with the Discoverer servlet.

    The advantage of using the Secure Tunneling communication protocol is that it is quicker than the Default option, because JRMP is not attempted first before failing and trying again using HTTPS.

    For more information about specifying this option, see Section 13.6.3.5, "How to set up Discoverer Plus to use the Secure Tunneling communication protocol".

Note: If you deploy Discoverer Plus over HTTPS, end users must use an HTTPS URL. If they use an HTTP URL, Discoverer does not start (for more information about troubleshooting HTTPS problems, see Section E.8, "Discoverer Plus reports RMI error").

13.6.3.2 How to display Communications Protocols on the Discoverer Plus Configuration page in Fusion Middleware Control

You use the Discoverer Plus Configuration page in Fusion Middleware Control to specify a Discoverer Plus communication protocol. For example, if you want to encrypt Discoverer Plus data, you might want to configure Discoverer Plus to use the HTTPS communication protocol.

To display the Discoverer Plus communication protocols in Fusion Middleware Control:

  1. Display the Fusion Middleware Control Discoverer Home page (for more information, see Section 4.1.3, "How to display the Fusion Middleware Control Discoverer Home page and Discoverer component Home pages").

    Surrounding text describes em_main.gif.
  2. Select Discoverer Plus in the Components area to display the Fusion Middleware Control Discoverer Plus Home page.

    Surrounding text describes em_plus.gif.
  3. Click Configure to display the Discoverer Plus Configuration page.

    Surrounding text describes oem6.gif.

13.6.3.3 How to set up Discoverer Plus to use the Default communication protocol

To set up Discoverer Plus to use the Default communication protocol:

  1. Display Fusion Middleware Control and navigate to the Discoverer Plus Communication Protocols area in the Discoverer Plus Configuration page (for more information, see Section 13.6.3.2, "How to display Communications Protocols on the Discoverer Plus Configuration page in Fusion Middleware Control").

  2. Select the Default option from the Communication Protocols options.

  3. Click Apply to save the details.

  4. Give Discoverer Plus users the URL of the Discoverer servlet:

    For example, http://<host.domain>:80/discoverer/plus

    The Discoverer Plus applet attempts to use JRMP. If JRMP is not available, the Discoverer Plus applet uses HTTP or HTTPS (depending on the URL) to communicate with the Discoverer servlet.

    Note: This option works regardless of whether the applet is running inside or outside a firewall. However, it is slower outside the firewall because JRMP is tried first. For more information about the other options on this page, refer to Section 13.6.3.1, "About specifying a Discoverer Plus communication protocol".

13.6.3.4 How to set up Discoverer Plus to use the Tunneling communication protocol

You use the Tunneling option when you want to run Discoverer Plus over HTTP.

To set up Discoverer Plus to use the Tunneling communication protocol:

  1. Display Fusion Middleware Control and navigate to the Discoverer Plus Communication Protocols area in the Discoverer Plus Configuration page (for more information, see Section 13.6.3.2, "How to display Communications Protocols on the Discoverer Plus Configuration page in Fusion Middleware Control").

  2. Choose the Tunneling option from the Communication Protocols options.

  3. Click Apply to save the details.

  4. (optional) If you are using a firewall, open the appropriate port in the firewall to accept HTTP or HTTPS traffic as appropriate.

  5. Give Discoverer Plus users the URL of the Discoverer servlet:

    For example, http://<host.domain>:80/discoverer/plus

    The Discoverer Plus applet uses the same protocol to communicate with the Discoverer servlet as was originally used to download the applet itself (that is, either HTTP or HTTPS). This option works regardless of whether a firewall is being used.

13.6.3.5 How to set up Discoverer Plus to use the Secure Tunneling communication protocol

You use the Secure Tunneling option when you want to run Discoverer Plus over HTTPS.

To set up Discoverer Plus to use the Secure Tunneling communication protocol:

  1. Display Fusion Middleware Control and navigate to the Oracle BI Discoverer Plus Communication Protocols area in the Discoverer Plus Configuration page (for more information, see Section 13.6.3.2, "How to display Communications Protocols on the Discoverer Plus Configuration page in Fusion Middleware Control").

  2. Choose the Secure Tunneling option from the Communication Protocols options.

  3. Click Apply to save the details.

  4. (optional) If you are using a firewall, open the appropriate port in the firewall to accept HTTP or HTTPS traffic as appropriate.

  5. Give Discoverer Plus users the URL of the Discoverer servlet:

    For example, https://<host.domain>:4443/discoverer/plus

The Discoverer Plus applet uses the HTTPS protocol to communicate with the Discoverer servlet.

When a Discoverer end user starts Discoverer Plus for the first time on a client machine, they are prompted to confirm that they want to accept a default security certificate. Before selecting the Yes option on the Security Alert dialog, the Discoverer end user must install a Discoverer Plus security certificate on the client machine (for more information, see Section 2.5.1, "How to install a security certificate on a Discoverer Plus client machine").

13.7 Configuring End-to-End Secure Sockets Layer for Discoverer

If you have Oracle HTTP Server and Oracle Web Cache front-ending the Oracle WebLogic Server that hosts Oracle BI Discoverer, then to enable end-to-end Secure Sockets Layer (SSL) you must perform these steps:

  1. Enable SSL for Single Sign-On. For more information, see "Enabling SSL for the Single Sign-on Server".

  2. Enable SSL for the Oracle Web Cache end points. To enable inbound and outbound SSL for Web Cache, follow the procedures described in the section "Enabling SSL for Oracle Web Cache Endpoints" in Oracle Fusion Middleware Administrator's Guide.

  3. Enable SSL for the Oracle HTTP Server virtual hosts. To enable inbound and outbound SSL for Oracle HTTP Server virtual hosts, follow the procedures described in the section "Enabling SSL for Oracle HTTP Server Virtual Hosts" in Oracle Fusion Middleware Administrator's Guide.

  4. If Single Sign-On is enabled, modify the virtual host configuration. For more information, see "Modifying the Virtual Host Configuration".

  5. Re-register the partner applications with the SSO server as described in the section "Re-registering mod_osso".

    If you are using Oracle Access Manager, see section "Registering an OSSO Agent (mod_osso)" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

  6. Enable the WebLogic Plug-in parameter. For more information, see "Enabling WebLogic Plug-In".

Enabling SSL for the Single Sign-on Server

To manually configure SSL, refer to the information on enabling SSL in the Oracle Application Server Single Sign-On Administrator's Guide. If you are going to configure OracleAS Single Sign-On behind a reverse proxy server, you should refer to the information on deploying OracleAS Single Sign-On with a proxy server, in the Oracle Application Server Single Sign-On Administrator's Guide at:

http://download.oracle.com/docs/cd/B28196_01/idmanage.1014/b15988/toc.htm

Note:

As the OracleAS Single Sign-On middle-tier partner application is still non-SSL, you must re-register it as non-SSL. Therefore, the re-registration of mod_osso needs to specify the non-SSL URL of the OracleAS Single Sign-On middle tier for the mod_osso_url parameter to ssoreg.

Refer to the information on registering mod_osso in the Oracle Application Server Single Sign-On Administrator's Guide.

Modifying the Virtual Host Configuration

If you are using SSL connections, then add the ServerName entry in the ssl.conf file of the Oracle HTTP Server virtual host and specify the Oracle Web Cache listening port as follows:

  1. Open the Oracle HTTP Server home page in the Oracle Enterprise Manager 11g Fusion Middleware Control, select Administration, and then Advanced Configuration.

  2. Select the ssl.conf file, add the ServerName entry for the virtual host and specify the Oracle Web Cache SSL listening port as shown in the following example:

    <VirtualHost *:OHS_listening_port>
    UseCanonicalName On
    ServerName https://www.abc.com:8094
    <IfModule ossl_module>
    SSLEngine on
    SSLVerifyClient None
    SSLCipherSuite
    SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SH 
    A,SSL_RSA_WITH_DES_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_C BC_SHA
    SSLCRLCheck Off
    SSLWallet "wallet_location"
    

    Ensure that wallet_location specifies the full path of the custom wallet as shown in the following example:

    SSLWallet "$ORACLE_INSTANCE/config/OHS/ohs1/keystores/default"
    

Re-registering mod_osso

If you have enabled Oracle Single Sign-On authentication (that is, if you have registered mod_osso), follow these steps to re-register mod_osso:

  1. On the OracleAS Single Sign-On host, set the environment variables ORACLE_HOME and ORACLE_SID.

  2. On the OracleAS Single Sign-On host, run the ssoreg script, using the -remote_midtier option. The script is located at:

    (UNIX) ORACLE_HOME/sso/bin/ssoreg.sh
    (Windows)ORACLE_HOME\sso\bin\ssoreg.bat
    

    For example, on LINUX:

    $ORACLE_HOME/sso/bin/ssoreg.sh 
      -site_name www.abc.com
      -config_mod_osso TRUE
      -mod_osso_url https://www.abc.com:8094
      -update_mode MODIFY
      -remote_midtier
      -config_file ORACLE_INSTANCE/config/OHS/ohs1/osso.conf
      -admin_info cn=orcladmin
    
  3. Copy the osso.conf file to the Oracle HTTP Server instance where you have configured the virtual host for the web cache ssl port (ORACLE_INSTANCE/config/OHS/ohs1/osso.conf).

  4. Restart the Oracle HTTP Server using the following commands:

    ORACLE_HOME/bin/opmnctl stopall
    ORACLE_HOME/bin/opmnctl startall
    

Enabling WebLogic Plug-In

For SSL-enabled Discoverer, you must enable the WebLogic Plug-In Enabled option for the Oracle WebLogic Server Administration Server and the Managed Server (WLS_DISCO). For more information about configuring the WebLogic Plug-In Enabled option through the Oracle WebLogic Server Administration Console, see the section "Servers: Configuration: General" in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help at:

http://download.oracle.com/docs/cd/E14571_01/apirefs.1111/e13952/core/index.html.

13.8 Using Discoverer with Oracle Identity Management Infrastructure

Note: This section applies only if the Discoverer installation is associated with the Oracle Internet Directory and the Discoverer schemas. For more information, see Section 1.3, "About Oracle BI Discoverer installations."

Oracle Identity Management Infrastructure provides several services, including:

You can specify that Discoverer uses single sign-on to enable users to access Discoverer using the same user name and password as other Web applications.

Notes:

  • If you plan to use Oracle Single Sign-On (OSSO) 10g as a single sign-on solution for Oracle BI Discoverer 11g, you need to associate Oracle Identity Manager 11g with Oracle Single Sign-On (OSSO)10g before associating it with Oracle BI Discoverer 11g.

  • If you plan to use Oracle Access Manager 11g for single sign-on, skip Oracle Identity Manager 11g association during the Oracle BI Discoverer configuration.

For more information about the single sign-on options and recommendations, see the chapter "Evaluating Single Sign-On Installations" in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

This section contains the following topics:

For more information about Oracle Identity Management Infrastructure, see Oracle Fusion Middleware Getting Started with Oracle Identity Management.

13.8.1 Using Discoverer with Oracle Single Sign-On

This section describes Oracle Single Sign-On and how to use it with Discoverer.

13.8.1.1 About Oracle Single Sign-On and Discoverer

Oracle Single Sign-On is a component of Oracle Fusion Middleware that enables users to access multiple Web applications (for example, Oracle BI Discoverer and Oracle Portal) using a single user name and password that is entered once.

Note: Oracle Single Sign-On is implemented using Oracle Single Sign-On Server.

When you install Oracle, the Oracle Single Sign-On service is installed automatically, but it is not enabled by default for Discoverer. For information about how to enable Oracle Single Sign-On, see Section 13.8.1.2, "How to enable and disable Single Sign-On for Discoverer".

Discoverer connections work in both Single Sign-On and non-Single Sign-On environments. In an Oracle Single Sign-On environment, if a Discoverer end user starts Discoverer without having been authenticated by Oracle Single Sign-On, the user is challenged for Single Sign-On details (user name and password). Having provided Single Sign-On details, the user can display the Discoverer connections page and start Discoverer without having to enter a user name or password again.

For more information about how Oracle BI Discoverer works with Oracle Portal and Single Sign-On, see Section 13.8.1.3, "An example showing how Discoverer works with Oracle Portal and Single Sign-On".

Notes

  • Oracle Single Sign-On does not work within BIS, EDW, or DBI Web pages.

  • Oracle Single Sign-On, can be enabled for both Discoverer Plus and Discoverer Viewer, but not for a single Discoverer component. For example, you cannot enable Oracle Single-Sign-On for Discoverer Plus only.

When you install Oracle, the Oracle Single Sign-On service is installed automatically, but it is not enabled by default for Discoverer. For information about how to enable Oracle Single Sign-On, see Section 13.8.1.2, "How to enable and disable Single Sign-On for Discoverer".

13.8.1.2 How to enable and disable Single Sign-On for Discoverer

You enable and disable Single Sign-On on the Oracle BI Discoverer instance.

To enable and disable Single Sign-On, do the following:

  1. Open the mod_osso.conf file in a text editor (for more information about the location of configuration files, see Section A.1, "Discoverer File Locations").

  2. To enable Single Sign-On for Discoverer, add the following text to the end of the file:

    <Location /discoverer/plus>
    
    require valid-user
    AuthType Osso
    
    </Location>
    <Location /discoverer/viewer>
    
    require valid-user
    AuthType Osso
    
    </Location>
    <Location /discoverer/app>
    require valid-user
    AuthType Osso
    </Location>
    
  3. To disable single sign-on for Discoverer, remove the following text from the file:

    <Location /discoverer/plus>
    
    require valid-user
    AuthType Osso
    
    </Location>
    <Location /discoverer/viewer>
    
    require valid-user
    AuthType Osso
    
    </Location>
    
    <Location /discoverer/app>
    require valid-user
    AuthType Osso
    </Location>
    
  4. Save the mod_osso.conf file.

  5. Restart Oracle HTTP Server by running the following opmnctl command (located at ORACLE_INSTANCE\bin directory):

    opmnctl stopall
    opmnctl startall
    

Notes

  • Do not enable Oracle Single Sign-On for the URL /discoverer/portletprovider. Discoverer relies on Oracle Portal to protect the /discoverer/portletprovider URL. In other words, do not specify the Location value as /discoverer, as follows:

    <Location /discoverer/portletprovider>

    require valid-user

    AuthType Osso

    </Location>

  • Do not enable Oracle Single Sign-On for the URL /discoverer/wsi. Discoverer relies on Oracle Bi Publisher to protect the /discoverer/wsi URL. In other words, do not specify the Location value as /discoverer, as follows:

    <Location /discoverer/wsi>

    require valid-user

    AuthType Osso

    </Location>

  • Ensure that the OssoIPCheck parameter value in the mod_osso.conf file is set to off.

  • If you use Oracle Web Cache to cache Discoverer Viewer pages, note that caching for Discoverer does not work if Single Sign-On is enabled.

13.8.1.3 An example showing how Discoverer works with Oracle Portal and Single Sign-On

When you publish Discoverer content in a portlet on an Oracle Portal page, you give portal users access to the Discoverer workbooks and worksheets. However, portal users accessing Discoverer workbooks only see data to which they have database access. In other words, two different users accessing the same workbook might see different data, depending on their database privileges. For more information, see Oracle Fusion Middleware Guide to Publishing Oracle Business Intelligence Discoverer Portlets.

To illustrate how Oracle BI Discoverer works with Oracle Portal, consider the following example:

Imagine that there are two Single Sign-On users:

  • User SSO-A has a private connection Conn-A pointing to DBUSER-A@discodb, EUL-Marketing.

  • User SSO-B has a private connection Conn-B pointing to DBUSER-B@discodb, EUL-Marketing.

User SSO-A using connection Conn-A creates two workbooks Workbook 1 and Workbook 2 in the Marketing EUL. User SSO-A uses Discoverer Plus to share Workbook 2 with DBUSER-B.

User SSO-B using connection Conn-B creates two workbooks Workbook 3 and Workbook 4 in the Marketing EUL. User SSO-B uses Discoverer Plus to share Workbook 4 with DBUSER-A.

This situation is shown in the figure below:

Figure 13-1 Single Sign-On users creating workbooks

Surrounding text describes Figure 13-1 .

Now imagine that user SSO-A creates a List of Worksheets portlet using Conn-A, and chooses the 'Use user's database connection' option in the Logged In users section (that is, in the Select Database Connections page in the Discoverer Portlet Provider).

When user SSO-A accesses the List of Worksheets portlet, worksheets in the following workbooks are available:

  • Workbook 1

  • Workbook 2

  • DBUSER-B.Workbook 4

When user SSO-B accesses the same List of Worksheets portlet, worksheets in the following workbooks are available:

  • Workbook 3

  • Workbook 4

  • DBUSER-A.Workbook 2

This situation is shown in the figure below:

Figure 13-2 Single Sign-On users accessing Discoverer portlets

Surrounding text describes Figure 13-2 .

13.8.2 Using Discoverer with Oracle Access Manager

Oracle Access Manager (OAM) is a component in Oracle Fusion Middleware that provides single sign-on solution to access multiple Web applications using a single user name and password. Oracle Access Manager is the recommended enterprise-wide single sign-on solution. This section describes how to use Oracle Access Manager with Oracle BI Discoverer and contains the following topics:

13.8.2.1 Single Sign-On using Oracle Access Manager 11g

Oracle BI Discoverer 11g Release 1 (11.1.1) supports single sign-on using Oracle Access Manager 11g. Oracle recommends that you install Oracle BI Discoverer and then configure Oracle Access Manager 11g. Follow the procedure below to install and use Oracle Access Manager with Oracle BI Discoverer:

  1. Install and Configure Oracle BI Discoverer. For more information, see Oracle Fusion Middleware Installation Guide for Oracle Portal, Forms, Reports and Discoverer.

  2. Install Oracle Access Manager as described in the chapter "Installing Oracle Identity and Access Management (11.1.1.5.0)" in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

  3. Configure Oracle Access Manager and ensure that the Oracle Access Manager server is running after the deployment. For more information, see chapter "Configuring Access Manager" in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

  4. Register the OSSO agent (mod_osso) wtih OAM 11g. For more information about how to register the OSSO agent, see section "Registering an OSSO Agent (mod_osso)" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

  5. Edit the mod_osso.conf file as follows:

    1. Copy the mod_osso.conf file from the
      $MW_HOME/instance_name/config/OHS/ohs1/backup/disabled directory to the
      $MW_HOME/instance_name/config/OHS/ohs1/moduleconf directory.

    2. Create a folder named 'osso' under the location $MW_HOME/instance_name/config/OHS/ohs1/ and copy the osso.conf file generated after registration.

    3. Edit the mod_osso.conf file from the location $MW_HOME/instance_name/config/OHS/ohs1/moduleconf and add the following lines:

      LoadModule osso_module "${ORACLE_HOME}/ohs/modules/mod_osso.so"
      
      <IfModule osso_module>
      
        OssoIpCheck off
        OssoIdleTimeout off
        OssoHttpOnly off
        OssoSecureCookies off
        OssoConfigFile MW_Home1/asinst_1/config/OHS/ohs1/osso/osso.conf
      
        <Location /discoverer/plus>
        require valid-user
        AuthType Osso
        </Location>
      
        <Location /discoverer/viewer>
        require valid-user
        AuthType Osso
        </Location>
      
        <Location /discoverer/app>
        require valid-user
        AuthType Osso
        </Location>
      
      </IfModule>
      
    4. Save the mod_osso.conf file.

    5. Restart Oracle HTTP Server by running the following opmnctl commands located at ORACLE_INSTANCE\bin directory:

      opmnctl stopall
      opmnctl startall
      
  6. Restart the Oracle Access Manager server that is hosting the OSSO Agent.

  7. Verify whether the Oracle BI Discoverer URLs can be accessed through the OAM authentication screen.

13.8.2.2 Upgrading your Oracle Single Sign-On 10g Environment

If you have already configured the Oracle Single Sign-On 10g service that is installed with Oracle BI Discoverer 11g, to use the OAM single sign-on solution for Discoverer, you can upgrade the existing Oracle Single Sign-On 10g Release 2 to Oracle Access Manager 11g. For more information about upgrading to OAM, see the chapter "Upgrading Your Oracle Single Sign-On Environment" in Oracle Fusion Middleware Upgrade Guide for Oracle Identity Management.

Note:

You must retain the existing Oracle Single Sign-On 10g host name and port number. Use the same host name and port number when you install OAM 11g.

After you upgrade Oracle Single Sign-On to Oracle Access Manager, you must replace the existing osso.conf file with the new configuration file that is generated during the upgrade process. The configuration file created during the upgrade process is located in the ORACLE_HOME/upgrade/temp/oam directory as Discovererinstance_hostname_osso.conf. Rename this file as osso.conf and copy the osso.conf file to the ORACLE_INSTANCE/config/OHS/ohs1 directory. Replace the existing osso.conf file in this directory with the new file.

Note:

Create a copy of the existing osso.conf file before you replace it with the new configuration file. Later, if you want to use Oracle Single Sign-On, copy this configuration file back to the ORACLE_INSTANCE/config/OHS/ohs1 directory and restart Oracle HTTP Server.

To enable and disable single sign-on for Oracle BI Discoverer, edit the mod_osso.conf file as described in Section 13.8.1.2, "How to enable and disable Single Sign-On for Discoverer".

13.8.3 Using Discoverer without Oracle Single Sign-On or Oracle Access Manager

If you are not deploying Discoverer with Single Sign-On or Oracle Access Manager, end users must confirm the database password each time a private connection is used. In other words, when a Discoverer end user chooses a private connection for the first time in a browser session, they are prompted to confirm the database password.

If the end user closes the Web browser and then starts the Web browser again (that is, creates a new browser session), they are prompted to confirm their database password. End users do not have to confirm passwords for public connections. For more information, see Section 3.2, "What are the types of Discoverer connections?".

Notes

  • To store private Discoverer connections in non-Oracle Single Sign-On environments, cookies must be enabled in the Web browser.

  • In non-Oracle Single Sign-On environments, a Discoverer end user can only access private connections created using the current machine and current Web browser. If an end user wants to use a different machine or different Web browser, they must re-create the private connections.

13.9 Discoverer support for Single Sign-On details propagation

This section explains how you can use Discoverer with a Virtual Private Database (VPD) using Oracle Single Sign-On details, and contains the following topics:

Notes

13.9.1 Introducing Virtual Private Databases, Single Sign-On, and Discoverer

The Oracle database's (Enterprise Edition Release 1 and later) powerful Virtual Private Database (VPD) feature enables you to define and implement custom security policies. Among other things, the VPD feature enables you to enforce fine-grained access control based upon attributes of a user's session information (referred to as application context). This VPD functionality is commonly employed as a way of controlling access to data using the currently logged-on user's Oracle Single Sign-On identity. For more information about setting up a VPD, see Oracle Database Advanced Application Developer's Guide.

If Discoverer has been configured to require Oracle Single Sign-On authentication, Discoverer can pass one of the following values to the database (as the CLIENT_IDENTIFIER attribute of the built-in application context USERENV):

  • The Global User ID (GUID) associated with the Discoverer end user's Oracle Single Sign-On user name

    This option is true for Discoverer (version 11.1.1 and later) if GUID is selected in the User ID field on the Discoverer Administration page in Oracle Fusion Middleware Control.

  • The Discoverer end user's Oracle Single Sign-On user name

    This option is true for either of the following:

    • Discoverer (versions earlier than 11.1.1) - if Discoverer has been configured to require Oracle Single Sign-On

    • Discoverer (version 11.1.1 and later) - if SSO User Name is selected in the User ID field on the Discoverer Administration page in Oracle Fusion Middleware Control

Providing a VPD policy based on GUID or Oracle Single Sign-On user names has been implemented in the database, the data returned to a Discoverer worksheet is restricted to the data that the respective GUID or Oracle Single Sign-On user is authorized to access (and depending on the conditions described in the previous paragraphs).

You can optionally add user-defined PL/SQL statements to both database LOGON (and subsequent) triggers and to a Discoverer trigger (eul_trigger$post_login) to use the GUID or Oracle Single Sign-On user name to further control the data that is returned. You can use Discoverer triggers and the database separately or together.

13.9.2 Example for using GUID or SSO user name to limit Discoverer data

Note: To enable the Oracle Single Sign-On user name to limit Discoverer data, in Discoverer (version 11.1.1 and later), SSO User Name must be selected in the User ID field on the Discoverer Administration page in Oracle Fusion Middleware Control.

The Discoverer manager at Acme Corp. does the following:

  1. Configures the Discoverer middle tier machines so that Oracle Single Sign-On authentication is necessary to access the Discoverer URLs.

  2. Creates a Discoverer public connection called 'Analysis', that has access to a workbook called 'Sales'.

  3. Creates a VPD policy against the base tables of the workbooks. The VPD policy determines the data that is returned, based on the value of a variable called 'CONTEXT1'.

  4. Creates a database LOGON trigger that sets variable CONTEXT1 to the value of the GUID (extracted from the application context information passed to the database by Discoverer).

    To enable the Oracle Single Sign-On user name to limit Discoverer data, in step 4 replace the GUID, with the Oracle Single Sign-On user name.

The Sales workbook is used by two Discoverer users at ACME Corp., Fred Bloggs and Jane Smith. A typical workflow for these two users is shown below:

  1. User 'Fred.Bloggs' authenticates through Oracle Single Sign-On and accesses the top level Discoverer URL.

  2. Fred selects the public connection 'Analysis', and opens the workbook 'Sales'.

  3. Fred views the data in the default worksheet, and then logs out.

  4. User 'Jane.Smith' authenticates through Oracle Single Sign-On and accesses the top level Discoverer URL.

  5. Jane selects the public connection 'Analysis', and then opens workbook 'Sales'.

  6. Jane views the data in the default worksheet.

Jane sees different data to Fred, despite the identical database connection, workbook, worksheet and database query. The difference is determined by the VPD policy being based on the GUID (or Oracle Single-Sign-On user name).

13.9.3 About tasks for using SSO user names to limit Discoverer data

Before the data shown in a Discoverer worksheet can be controlled using Oracle Single Sign-On user names, a Discoverer manager performs the following tasks:

13.9.4 How to set up Worksheet Portlets to show data based on GUID, SSO or OAM user name

Having created a VPD policy in the database that uses GUIDs, Oracle Single Sign-On (SSO), or Oracle Access Manager (OAM) user names to determine the data that users can access, you can set up a Discoverer Worksheet portlet to only show the data that can be accessed by the current SSO/OAM user name.

To specify that users only see the data they can access with their SSO or OAM user name:

  1. In the Users Logged In region of the Select Database Connections setup page for the Discoverer Worksheet Portlet.

  2. Select the Display different data using the Publisher's connection option.

    Surrounding text describes portal_14.gif.

    When you select the above option, Discoverer passes the worksheet portlet user's SSO or OAM user name to the database. The VPD policy can then use the GUID or SSO/OAM user name to restrict the data that is returned to the worksheet portlet.

13.9.5 When to use other options in the Users Logged In region of the Select Database Connections page

If you want all users to always see the same data from the database regardless of their own database user names, or SSO/OAM user names, do the following in the Select Database Connections setup page for the Discoverer Worksheet Portlet:

  1. Select the Display same data to all users using <Publisher's Connection> option.

If you want users to initially see the same data from the database (regardless of their own database user names or SSO/OAM user names) but to give them the option of specifying an alternative database user name:

  1. Select the Display different data by allowing users to customize database connection option.

  2. Select the Show default data using <Publisher's Connection> check box.

13.9.6 How to modify database LOGON (and subsequent) triggers to use the GUID, SSO, or OAM user name

You can modify database LOGON (and subsequent) triggers to use the GUID or SSO/OAM user name passed by Discoverer to further control the data that is available to the SSO/OAM user. For example, you might want to call custom PL/SQL functions that take the GUID or SSO/OAM user name to perform application specific initialization.

To modify database triggers to use the GUID, SSO or OAM user name:

  1. Create a suitable database trigger.

  2. Add the required code to manipulate the GUID or SSO/OAM user name.

    Tip: To return the GUID or SSO/OAM user name passed by Discoverer, query the CLIENT_IDENTIFIER attribute of the USERENV application context namespace using the following function call:

    SYS_CONTEXT('USERENV', 'CLIENT_IDENTIFIER')

Notes

  • The GUID or SSO/OAM user name passed by Discoverer is available as early as the execution of the database LOGON trigger.

  • If Discoverer is not configured to use Oracle Single Sign-On, the SYS_CONTEXT function call returns NULL.

  • The SSO user name is available with Oracle9i (Release 1 and later) databases.

13.9.7 How to use the eul_trigger$post_login trigger

You can use the eul_trigger$post_login trigger instead of, or with, the database LOGON (and subsequent) triggers to further control the information that is displayed in a Discoverer worksheet based on the GUID or Oracle Single Sign-On user name. Use the eul_trigger$post_login trigger (rather than the database triggers) if:

  • you want trigger code to affect just Discoverer users, not all database users

  • you do not have DBA privilege (and therefore cannot modify the database LOGON (or subsequent) trigger code)

To use the eul_trigger$post_login trigger:

  1. Define a PL/SQL function in the database that:

    • has a return type of integer

    • does not take any arguments

  2. Add the required code to manipulate the GUID or Oracle Single Sign-On user name.

    Tip: To return the GUID or Oracle Single Sign-On user name passed by Discoverer, query the CLIENT_IDENTIFIER attribute of the USERENV application context namespace using the following function call:

    SYS_CONTEXT('USERENV', 'CLIENT_IDENTIFIER')

  3. Register the function with Discoverer Administrator and give it the following properties:

    • Name: eul_trigger$post_login

    • Return type: Integer

    • Arguments: none

      For more information about registering PL/SQL functions and using Discoverer EUL triggers, see the Oracle Fusion Middleware Administrator's Guide for Oracle Business Intelligence Discoverer.

  4. If the Database/EnableTriggers preference exists in the pref.txt file, set it to a value other than zero.

Notes

  • If the Database/EnableTriggers preference does not exist in the pref.txt file, do not create it.

  • If the Database/EnableTriggers preference does exist and you must change its value (that is, to make it nonzero), you must subsequently:

    1. Run the applypreferences script to apply the preference change.

    2. Stop and restart the Oracle BI Discoverer service for the change to take effect.

13.10 Frequently asked questions about security

This section contains common security questions and answers.

13.10.1 What is a firewall?

A firewall is one system or a group of several systems put in place to enforce a security policy between the Internet and an organization's network.

In other words, a firewall is an electronic 'fence' around a network to protect it from unauthorized access.

Figure 13-3 A typical Internet connection with a Client-side and Server-side firewall

Surrounding text describes Figure 13-3 .

Typically, an organization using a Web Server machine that communicates across the Internet has a firewall between its Oracle HTTP Server machine and the Internet. This is known as a Server-side firewall. Other organizations (or remote parts of the same organization) connecting to this Web Server machine typically have their own firewall, known as a Client-side firewall. Information that conforms to the organization's firewall policy is allowed to pass through the firewalls enabling server machines and client machines to communicate.

13.10.2 What is a demilitarized zone (DMZ)?

A demilitarized zone (DMZ) is a firewall configuration that provides an additional level of security. In this configuration, the DMZ is an extra network placed between a protected network and the Internet. Resources residing within the DMZ are visible on the public Internet, but are secure. DMZs typically hold servers that host a company's public Web site, File Transfer Protocol (FTP) site, and Simple Mail Transfer Protocol (SMTP) server.

Figure 13-4 A Demilitarized Zone (DMZ)

Surrounding text describes Figure 13-4 .

Firewall policies vary across organization and there are a wide variety of bespoke and off-the-shelf firewall packages in use.

A good firewall configuration assumes that resources in the DMZ will be breached, and if this happens, the firewall should minimize damage to the internal network and any sensitive data residing on the network. This involves two steps:

  • Move sensitive private resources (at a minimum, databases and application logic) from the DMZ to the internal network behind the internal firewall

  • Restrict access to sensitive private resources from the DMZ itself, and from internal networks

13.10.3 What is HTTPS and why should I use it?

The HTTPS protocol uses an industry standard protocol called Secure Sockets Layer (SSL) to establish secure connections between clients and servers.

The SSL protocol enables sensitive data to be transmitted over an insecure network, such as the Internet, by providing the following security features:

  • Authentication - a client can determine a server's identity and be certain that the server is not an impostor (and optionally, a client can also authenticate the identity of its server)

  • Privacy - data passed between the client and server is encrypted such that if a third party intercepts messages, the third party cannot unscramble the data

  • Integrity - the recipient of encrypted data knows whether a third party has corrupted or modified that data

You can tell when SSL is enabled in Discoverer as follows:

  • The URL to start Discoverer Plus begins with https://, and a closed padlock appears at the left hand side of the applet's status bar

    Note: To deploy Discoverer Plus over HTTPS, you must select the Secure Tunneling security protocol in Oracle Fusion Middleware Control (Section 13.6.3.5, "How to set up Discoverer Plus to use the Secure Tunneling communication protocol").

  • The URL to start Discoverer Viewer begins with https://, and a closed padlock or other equivalent symbol (browser dependent) appears in the browser's status bar

13.10.4 How do I configure Discoverer to work in an intranet

You configure Discoverer to work in an intranet as follows:

  • Discoverer Viewer

    Deploying Discoverer Viewer in an intranet (that is, inside a firewall) requires no additional configuration after an Oracle installation. Discoverer Viewer uses an HTTP connection.

  • Discoverer Plus

    Deploying Discoverer Plus in an intranet (that is, inside a firewall) requires no additional configuration after an Oracle installation. Discoverer Plus uses a direct connection using JRMP.

Figure 13-5 A typical network configuration for Discoverer in an intranet

Surrounding text describes Figure 13-5 .

13.10.5 How do I configure Discoverer to work through a firewall?

You configure Discoverer to work through firewalls with HTTP or HTTPS, as follows:

Figure 13-6 A typical firewall configuration for Discoverer using HTTP

Surrounding text describes Figure 13-6 .

13.10.6 Can I configure Discoverer to work through multiple firewalls?

Yes. If you are using HTTP or HTTPS, Discoverer works through multiple firewalls. For more information, see Section 13.10.5, "How do I configure Discoverer to work through a firewall?"

13.10.7 How do I configure Discoverer to use encryption in an intranet?

You configure Discoverer to use encryption as follows:

  • Discoverer Viewer

    Configure mod_ossl to use HTTPS (for more information, see Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server) and deploy Discoverer Viewer on an HTTPS URL.

  • Discoverer Plus

    Configure mod_ossl to use HTTPS (for more information, see Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server) and deploy Discoverer Plus on an HTTPS URL. You must change the Discoverer Plus communication protocol to Secure Tunneling (for more information, see Section 13.6.3.5, "How to set up Discoverer Plus to use the Secure Tunneling communication protocol").

13.10.8 How do I configure Discoverer to use encryption through firewalls?

You configure Discoverer to use encryption through firewalls as follows:

Figure 13-7 A typical firewall configuration for Discoverer using HTTPS

Surrounding text describes Figure 13-7 .

13.10.9 How can I verify that Discoverer is encrypting communications?

In Discoverer Viewer, ensure that client browsers display a closed padlock or other equivalent symbol (browser dependent) in the Discoverer Viewer browser's status bar.

In Discoverer Plus, ensure that the client displays a closed padlock symbol in the bottom left-hand corner of the Discoverer Plus applet window.

13.10.10 Can I configure Discoverer for both intranet users and users accessing Discoverer through a firewall?

Yes, you can configure Discoverer for both intranet users and Internet users. For example, if you use the Default Discoverer Plus communication protocol:

  • sessions connecting from inside the firewall use a direct JRMP connection because JRMP is a direct connection that only works inside a firewall

  • sessions connecting from outside the firewall automatically use an HTTP or HTTPS connection (depending on the URL)

13.10.11 Can I use Discoverer with a NAT device?

Yes, you can deploy Discoverer using any standard Network Address Translation (NAT) device.