OBIEE Lockdown - Part 1

Security Recommendations in Oracle Business Intelligence Installations

There are three key security recommendations for installing and securing 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).

Change the default passwords for the RPD, as everyone knows “Admin123.”  If you are promoting an 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

Use whatever is standard in your organization for managing authentication (be it OID, Active Directory, or some other sort of LDAP). Not only does it improve user experience by removing the need to memorize yet another username/password, but it also saves time for 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, the Administration Tool does not allow development separation within the repository objects (one needs to be an administrator to edit the RPD file – no way around it), hence anyone with the RPD/Admin password can do pretty much anything within the RPD. At this time, there are limited built-in options to audit or keep track of the RPD development changes. One must rely on a 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 an overhead associated with maintaining it, especially during active development periods. Another option would be to use an Administration tool utility to create metadata repository document on a regular basis and track deltas. Finally, more advanced options would include MUDE (multi user development environment) projects and XML export.

OBIEE Migrating Users and Security

So you have built your repository in development, tested how users interact with the data in the presentation layer, and now is the time to promote your work to the live environment.

If you have done your homework, you'll have put some effort into security while building the repository in development (it's always more difficult to bolt on security than it is to pause and design in security from the start).

So here you are in development, you've created your roles and some representative users. You could unpick the security behind the roles and users, or you could export them (users and roles) from your development environment and import them up the line into a pre-production environment. (Probably best to test that it all works before you do it for real.)

So, how does this all work; the security model is maintained in the weblogic console side of OBIEE, and the whole process of importing settings is additive only. By this I mean, that existing settings remain untouched, if a user is in one group prior to the new security import, and the import has that user in another group, the user will end up in two groups - test it for yourself - probably the best way to learn.

Exporting Weblogic OBIEE Users and Groups

So to export:
Login to your console and in the left hand side click on "Security Realms", then, when the screen refreshes, click on "myrealm" in the right panel. Select the Migration tab.

The process is the same for both export and import. For export select the export sub-tab. Designate a directory ON THE SERVER, not your machine, the server. This directory must exist. Click the button and within a second or two the job's done.

Weblogic Security Files

If you navigate to the server directory you designated you'll see 5 files.

Importing Weblogic OBIEE Users and Groups

Move the directory and files to the server where they are to be imported and open the console for that server, and navigate to the Migration tab, just as you did when exporting the security realm.

This time select the "Import" sub-tab, fill in the directory details and click "save". You should then be presented with a screen like below.

Now, the actual testing of permissions I'll leave to you but you will immediately be able to see the new users and groups by select from the tabs on the screen.