Saturday, June 13, 2009

Discoverer and LDAP

Even after Oracle is tightly integrating its components , something is left behind which makes the application completely unusable sometimes.
I had a Discoverer instance which has to be integrated with Single SignOn. This is quite possible and it works perfect.

But after login in to the application with single signon user, there is a possibility for re-using the SSO user in the database by registering the target database with the Oracle Internet Directory.

I am here just making a link to a demo where the integration is quite explained briefly.

Following it a database can be registered , I registered the database where EUL resides with OID.
Now from the database I could login as the oid user.

Now I am accessing discoverer and connecting as the OID user (DISOC1).
I created a workbook and saved it.

Now I am accessing discoverer and connecting as another OID user (DISOC2) and I am able to see the workbook created by the previous user(DISOC1).

At the backend the EUL5_DOCUMENTS has the DOC_CREATED_BY as the GLOBAL SCHEMA USER instead of DISOC1.

What could be the reason ?
I asked the same to Oracle Discoverer Support and got a feedback
"ER 5637910 DISCOVERER (OID SUPPORT) is currently at Status: 23,Scheduled for Future Release, however no timeframe for inclusion in the Disco product has been included in the ER. So not firm date for this functionality has been released. That means it will not be in Disco 11g, possibly 12g."

This issue is not seen in APPS mode EUL which is setup in Oracle E-Business Suite.

Good , now as usual we have to look for work arounds which can make this work which is under Oracle Standards.

Here are some tips to achive it.

I managed to use Oracle Internet Directory plugins to create and maintain the user in the database.
The plugins created the user by mapping to the DN in OID using the option in create user "globally identified as" when a user is created from the OIDDAS page.
Ex: create user test globally identified as 'cn=test,cn=users,dc=testdomain,dc=com';

Here the user in the database does not hold a seperate password but rather share the one from the OID.
Also there are special pluginscreated for user modification and deletion action.

Rest I managed using Roles in Enterprise Security Manager and still have the user management from OIDDAS.

The OID Plugins are quite interesting and once used to it , one can make use of it in different areas.

The purpose of this plugin and user management is to make sure the EUL5_DOCUMENTS records the login username in DOC_CREATED_BY.
Once Oracle Supports delivers a model which can perform this then I have to just switch off my plugins and delete all the users OID users in the database.
I have taken measure to store the scheduled workbooks in a seperate repository so that the user schema does not own any objects.

I hope this can help somebody who is developing a similar logic.

Popular Posts