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 







Authenticating Discoverer 9iAS Against A Non-Oracle LDAP Server

Oracle Tips by Burleson Consulting

Authenticating Discoverer 9iAS Against A Non-Oracle LDAP Server

I had the following email through from someone who'd read my recent article on integrating 9iAS and 9i Logins.

"I read your article on integrating discoverer 9iAS SSO logins with 9i db logins.Is it possible to integrate third party LDAP servers with discoverer viewer to enable authentications using this LDAP?. We are not using 9ias portal or OID here but considering other alternatives. If this is possible , can you please explain in detail how this integration can be achieved."

My first thoughts on this were:

"Good question. It's not something i've tried myself, and I've not heard of anyone 'in the field' authenticating Discoverer Viewer or Plus against a non-Oracle LDAP server.

What I suspect would be Oracle's advice, would be to

  • Install your 9iAS infrastructure mid-tier as normal (OID and all)
  • Install your 9iAS applications mid-tier as normal, with the BI & Forms option
  • Use the 9iAS OID DIP utility to synchronise the 9iAS OID LDAP server with your existing LDAP server

The LDAP instance that houses the Discoverer login information presumably has additional custom attributes that aren't found in your existing LDAP server. I would imagine that the only supported way of working with your existing LDAP data would be to sync it with the 9iAS OID instance, as I don't think it's possible to point the Discoverer OC4J application at a non-9iAS LDAP server. Certainly you can detach the Discoverer application from the 9iAS Farm, but then it runs in 'non-Single Sign-on' mode, effectively without any user authentication. On thing to bear in mind however, is that by licensing Discoverer Viewer/Plus, you have to license 9iAS as a whole anyway, so there's no saving money-wise in using an alternative LDAP server.

Have you got an Oracle support contract? If so, raise it as a TAR. If you haven't, as it's an interesting subject, can you tell me a bit more about the LDAP server you're looking to use, and I'll see what I can come up with."

Following on from this, I got the following response;

"Thanks mark for your prompt response. I am working in a consulting firm where the client has asked us the possibility of disco integration with a third party LDAP server, he has not mentioned which server he would go with at this point but just wants to be sure while we give this solution to him that the integration could be possible."

I had a good think about this, and the more I thought about it, the more things were pointing towards using the 9iAS Infrastructure whatever, and using the OID synchronization tools to sync this with the other LDAP server. With this in mind, I wrote back, saying

"Just a thought - what role do you envisage the LDAP server having, in this proposed setup.

Currently the OID LDAP server sits within 9iAS infrastructure, and authenticates users (i.e. grants permission to view the /discoverer/viewer and discoverer/plus webpages), and also (I believe) stores details of their private connections. When a connection (public or private) is used, it then connects to the underlying EUL using normal a normal Oracle username, password and connect string.

If we took OID out of the equation, and therefore SSO (which I believe can only work against the OID LDAP server), what role would your replacement LDAP server have? Would you use it as an authentication mechanism for the Apache mid-tier server (to enable it to continue protecting the /discoverer/viewer and /discoverer/plus virtual directories) and if so, can Apache do this? My understanding is that, if you detach the Discoverer mid-tier app server instance from the app server farm, you can't protect inpidual directories any more, as the 'authtype Basic' method of protecting directories relies on SSO.

Thinking about it, what you'd probably like to happen is

1. users log in to an LDAP server, granting them access to network resources.

2. they bring up the /discoverer/viewer or /discoverer/plus URL, which will have been detached from the 9ias infrastructure, and therefore won't be running in the single-sign on environment. Therefore, there's no protection for the discoverer URLs.

3. at this point, they can create private connections to discoverer. These private connections held in cookies on the particular PC, and can be used by anyone logging on to the PC as that user.

4. The private connections store the database userid, password and connect string. They connect using this as normal.

5. At this point, however, your LDAP server hasn't really played a part, except if they need to log in to it at the start to get access to a PC. The LDAP server isn't referenced by Discoverer at all.

I think the crux of this, is that the only supported LDAP server for 9iAS is OID. If you want any meaningful security for Discoverer, you have to use the 9iAS infrastructure. Therefore, the only way you're going to be able to use your alternative LDAP server (or infact Microsoft Active Directory) is to use those alternative directories to sync with OID. Syncing with OID is fairly straightforward, and I think this is probably the best approach rather than trying to replace OID / 9ias Inf with another LDAP server."

Having got an answer back, it looks like this is what's going to happen;

"Thanks a lot for the detailed explanation. I think it suffices and explains almost all the doubts i had in my mind. Do let me know in case you find any doc on OID Synchronization. I think my client is kinda convinced now to go in for 9ias portal oid infrastructure. His only concern is if tomorrow they integrate this portal with applications which have alternate ldap authentication mechanisms what would be the best way.  I think your reply to that would be to sync the OID with these LDAP servers.Do let me know if you find any doc on how this could be done."

If anyone comes across an instance of Discoverer 9iAS authenticating against a non-Oracle LDAP server, or synchronizes a non-Oracle LDAP server with the 9iAS OID instance (particularly if Discoverer is involved) let me know.

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.




Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


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.