User Management in Oracle Business Intelligence Discoverer Desktop

Question

I am new to managing Oracle Business Intelligence Discoverer Desktop users. In the past they have been allowed to use shared accounts with passwords that do not change. I am very much against this and think they need to change their passwords every 90 days and have individual accounts. My users do not have access to SQL or the database server itself. I do not see a way for the users to change their passwords with the Discoverer tool.
I am wondering how you manager your users?
Do you require them to change their passwords?
If so, how did you implement this?
Thanks for your ideas.
Tim Boles

Answer 1

Hi,
This is a tricky one, because when the scheduled job runs the SSO user is not stored anywhere. You only know the database user.
The workaround must be to store the SSO user or organisation so that it is available when the scheduled job runs. However, this is not easy as the information must be stored against the batch run as two similar batch runs may have different organisations/SSO users. There are a number of ways you might do this, for example, adding the information into the batch run EUL table, changing the package which is created when the workbook is scheduled that gets run from the jobs queue so that the package sets the organisation. All the options would involve changing the supplied report batch code which probably would not be supported.
Maybe the easiest workaround is to use a custom table, and it work like this:
1. A database logon trigger or EUL post logon trigger would check the client_identier and get the organisation.
2. The organisation should then be stored in a database context. It is quicker than using a package variable.
3. The EUL5_BATCH_SECURE_REP package is modified so that when the workbook is scheduled the organisation is stored in a custom table along with the batch run id or database job id.
4. A database logon trigger on the batch repository user (which will be fired when the scheduled report runs) looks in the custom table for the batch run id or job id using the details from the current job. The current job id is available from the userenv context.
5. The organisation is then retrieved and the database context set so that the workbook runs correctly.
I appreciate that the details are a bit sketchy but hopefully this has given you some ideas.
Rod West