Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 







Oracle SSO for Discoverer

Expert Oracle Tips by Burleson Consulting

Enabling SSO Support For Discoverer - By Mark Rittman

Oracle Discoverer is the primary query and reporting tool that I use on data warehousing projects, and the latest version, Oracle Discoverer, comes bundled with the Oracle Application Server. With release 2 of 9iAS, Discoverer uses the Single Sign-on server (known as SSO) within 9iAS to provide authentication and security.

One thing that isn't immediately apparent when installing Oracle Application Server, however, is that Discoverer 9iAS doesn't use SSO by default, relying instead on 'public connections' which allow anyone to get access to Discoverer workbooks if they know the service URL.

This became apparent to me when migrating a client's installation of Discoverer from Discoverer 4i to Discoverer 9iAS. We migrated the EUL as normal, installed 9iAS with the BI & Forms option, and then accessed Discoverer, which brings up a 'connections' screen that allows you to select from a list of public connections.

Public Connections are set up from the 9iAS EMWebsite, supplying the username, password, EUL name and connect string, and all users then have to do, to log on to Discoverer, is click on a public connections link. However, this isn't all that secure, as any user can then navigate to the Discoverer URL and use the link without supplying a password. The answer to this is to enable SSO for Discoverer 9iAS, remove the public database links, and require users to log on via SSO and create their own private connections.

This is accomplished by editing a file called mod_osso.conf, found within your <ORACLE_HOME>/Apache/Apache/conf directory, where <ORACLE_HOME> is your middleware (BI & Forms) instance. It's best to edit this using a tool such as textpad, as it's in Unix format and the line feeds don't get picked up properly by notepad. Once you've opened the file, do the following;

1. Find the line # # Insert Protected Resources: .................

2. Add the following next to this line

<Location /discoverer/plus>
     require valid-user
     AuthType Basic
    <Location /discoverer/viewer>
     require valid-user
     AuthType Basic

This registers the Discoverer Plus and Viewer virtual directories with the Middleware Apache instance, and requires that users are authenticated before they can access them.

3. Find the line that says set OssoIPCheck off, and change it to OssoIPCheck On

This is something you should do anyway with 9iAS release 2, as it avoids a cookie redirection issue, and it'll be the default with 9iAS 9.0.4 when it comes out.

4. Restart your middleware instance, then log in to http://servername:7779/discoverer/plus (or viewer) - you should get the Single Sign-On username and password prompt now.

If you're using Discoverer Portlets on Oracle Portal, and you previously deployed them using public connections (because there was no way to create private connections), you should really recreate them again using private connections. You will need to log on to Discoverer with the username and password of the Portal user who owns the page that houses the Discoverer Portlets, and create a private connection to the EUL that the Discoverer workbooks are held in. Then, when you go to redeploy the Discoverer Portlet, you can select the Discoverer connection from the page owner's list of private connections, removing the need for public connections and therefore tightening up security. The deployed portlet then uses this private connection to refresh its data.

Bringing Discoverer  into the SSO environment should be one one of the first things that WebLogic administrators do after setting up the software. You can still create public connections should you wish, but users will now require authentication to access the Discoverer URL, and as a bonus, they'll now have a single username and password that grants them access to the complete range of App Server WebLogic components, such as Portal, Reports, and Oracle Forms.


Get the Complete
Oracle SQL Tuning Information 

The landmark book "Advanced Oracle SQL Tuning  The Definitive Reference"  is filled with valuable information on Oracle SQL Tuning. This book includes scripts and tools to hypercharge Oracle 11g performance and you can buy it for 30% off directly from the publisher.



Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.



Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster