Oracle Discoverer is the primary query and reporting tool that I use on data warehousing projects, and the latest version, Oracle 9iAS Discoverer, comes bundled with the Oracle 9i 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 9iAS, 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 using the URLs http://servername:7779/discoverer/plus and http://servername:7779/discoverer/viewer, 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>
<Location /discoverer/viewer>
require valid-user
AuthType Basic
</Location>
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 9iAS 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 9iAS into the SSO environment should be one one of the first things that 9iAS 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 9iAS components, such as Portal, Reports, and Oracle Forms.
7:40:37 PM 
|
