Security!... where do I start?

This post is going to discuss things to consider when setting up a basic security strategy in OBIEE, focusing mainly on User Authentication.

Security in OBIEE can be thought of as a 2 step process as a user logs into the system:
1. Authentication – Do you have access?
2. Authorization – How much access do you have?

Authentication
Think of this as just getting your foot in the door. During Authentication, OBIEE is simply determining if a user has access to the tool. Once someone logs into the system from the Logon screen, the Oracle BI Presentation Server (OBIEE web front end), creates two System Variables. One for the Username that was entered (:USER) and one for the Password that was entered (:PASSOWORD). These System Variables are then sent to the Oracle BI Server to check if a User has been set up with that combination of Username and Password. A User can be set up a few different ways…

Security Manager:

The easiest and most basic way to set someone up with a Username and Password is via the Security Manager. Once someone is set up in this manner, their Username (:USER) and Password (:PASSWORD) are stored on the Oracle BI Server. If the Username and Password entered in the Logon Screen match what’s stored on the Oracle BI Server, they are granted access to the tool. This approach should only be taken if just a few people need access to the tool. Adding an entire organization of people in this manner is tedious, time consuming, and difficult to maintain.

External Database:

Setting up a table with a complete set of User Information, including Username and Password, will allow OBIEE to verify security credentials using what’s called an Initialization Block. An Initialization Block is basically a SELECT statement sent to the User Information table to pull back Username and Password. It is then compared to the System Variables sent from the Logon screen. If there is a match in the User Information table, they are given access. Now the User doesn’t need to be entered through the Security Manager, and the User Information table can be maintained from the database. Additionally, a number of other Variables can be populated from your User Information table to be used during Authorization.

Care must be taken when creating the Initialization Block, as the order of the SELECT statement determines what information is applied to each Variable. For example, in the image below, the value of “full_name” will be applied to the Variable “DISPLAYNAME”.

Single Sign-On:

SSO allows Users a single point of access to all of their organization’s systems. This typically requires the use of an SSO product. View this blog entry for more information on SSO. http://oraclebiblog.blogspot.com/search/label/SSO

Once you iron out your approach with this first step in the process… You’re ready to tackle the task of setting up Authorization. I’ll cover this in a future post…

"Bullet Proof" SSO

The following pieces are a subset of info presented at Oracle OpenWorld's OBI SSO Unconference by Kevin McGinley and myself. The content framework was provided by John Andrzejek of BI Consulting Group.

The full presentation can be found via http://www.biconsultinggroup.com/OOW

Many organizations have enabled SSO (Single Sign-On) with OBI EE; however, not all have taken the appropriate steps to make it "Bullet Proof", aka next to impossible to hack. Until now!

Below is a typical OBI EE login path when SSO is not enabled. This method works well in an intranet environment where personal data is not available to be queried by OBI EE.



Many organizations have taken the step to enable SSO for OBI EE so their users do not have to enter/remember yet another username/password combination. SSO is more secure than the basic OBI EE login but is still susceptable to hackers tricking OBI EE into authorization.

In order to ensure a more robust/secure method of SSO with OBI EE, the following approach should be taken so that a hacker cannot trick OBI EE into thinking the user has been authenticated. This is handle by Step 4 (see pic below) whereby the user clicks on a link in their portal to go to OBIEE and the portal writes a Record to a database table and then the BI Server checks this record to make sure the user has been authenticated.

If the user was not properly authenticated by the Portal then OBI will deny the user access to OBI EE.