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.
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
thoughts on this were:
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
the 9iAS OID DIP utility to synchronise the 9iAS OID LDAP server with
your existing LDAP server
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."
from this, I got the following response;
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
thought - what role do you envisage the LDAP server having, in this
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.
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
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
Having got an
answer back, it looks like this is what's going to happen;
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."
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
Get the Complete
Oracle SQL Tuning Information
The landmark book
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
for 30% off directly from the publisher.