Security Recommendations in Oracle Business Intelligence Installations
This post provides three key security recommendations for installing OBIEE in your enterprise environment.
1. Be serious about password management.
It is important to lock down the OBIEE environment and changing default passwords after installation.
The passwords for weblogic user should not be simple to guess or widely distributed. The best practice is to have different passwords throughout the environments. Moreover, I’d recommend replacing “weblogic user” with another obfuscated username. The username and password combination should be different throughout the environments (at least the password).
I strongly suggest changing the default passwords for the RPD, since everyone knows “Admin123.” If you are using 1 RPD, your password for Dev, Test, and Prod RPDs should be different as well to avoid a possibility of a developer making changes in a wrong environment.
Do not use the administrative account to present reports to the users and avoid providing it to users, there is high risk of breaking/deleting something by accident. Consider automating deployments to avoid having to deal with passwords manually.
2. Take the authentication and authorization outside of OBIEE
Please use whatever is standard in your organization for managing authentication (be it OID, Active Directory, or some other sort of LDAP). Not only it would improve user experience by removing the need to memorize yet another username/password, but it also saves time of the development team. Remember: They are not in the user management business. Another great use case is the ability to push this functionality further by automating users’ authorization by managing LDAP groups’ memberships and mapping them to the OBIEE’s application roles.
3. RPD Security Objects
Unfortunately, Administration Tool does not allow development separation within the repository objects (one needs to be an administrator to edit RPD file – no way around it), hence anyone with the RPD/Admin password can do pretty much anything within the RPD. At this time, one has limited built-in options to audit or keep track of the RPD development changes. One must rely on custom developed solution if this functionality is important. An easy and practical option is to keep an XLS spreadsheet of the major development milestones. It’s simple; however, its disadvantage is that there is certain overhead associated with maintaining it, especially during active development period. Another option would be to use an Administration tool utility to create metadata repository document on a regular basis and track delta. Finally, more advanced options would include MUDE (multi user development environment) projects and XML export.