OBIEE11g Security

OBIEE11g security can be divided into 2 broad categories:

1. Controlling access to the components within BI domain(resource access security)
2. Controlling access to data(data access security)

Oracle BI integrates with Fusion Middleware's security platform:

Weblogic Console - management of users and groups for the embedded LDAP server that serves as the default identity store

Enterprise Manager - Management of policy store application roles that grant permissions to users, groups and other application roles

BI Admin tool - management of permissions for Presentation layer objects and business model objects in the repository.

OBIEE11g default security model includes:

1. An embedded directory server functioning as an identity store designed to hold all user and group definitions required to control authentication.

2. A file based policy store designed to hold the application role and permission grant mappings to users and groups require to control authorization. So, Policy store is nothing but a physical file that contains Application Roles, Application Policies and their corresponding mapping to Users and Groups. The file name is system-jazn-data.xml. The file exists under [MIDDLEWARE_HOME]\user_projects\bifoundation_domain\config\fmwconfig

3. A file based credential store designed to hold all user and system credentials required to control authentication or authorization.

Groups are logically ordered set of users. Users with similar needs are organized into groups for easier maintenance. Groups are then mapped to application roles to grant rights. By default, 3 groups are created: BIAdministrators, BIAuthors and BIConsumers

Application role defines the set of permissions that are granted to a user or a group. Application roles are defined in Fusion Middleware Control. The policy store contains the default application roles hierarchy. Default application roles are:
BISystem: Grants the permissions necessary to impersonate other users. This role is required by BI system components for intercomponent communication
BIAdministrator: Grants the administrative permissions necessary to configure and manage OBIEE installation. Any member of BIAdministrators group is explicitly granted this role and implicitly granted BIAuthor and BIConsumer roles.
BIAuthor: Grants the permissions necessary to create and edit content. BIAuthors group is explicitly mapped to this role
BIConsumer: Grants the permission necessary for a user to use the content created by other users.

Applications roles are in policy store while Groups are in Identity Store.

Application Policies are the authorization policies that an application uses for controlling access to its resources. They are defined in Fusion Middleware Control.

Object Level Permissions can be set at RPD and at  Catalog Presentation services Layer. At the RPD, you can navigate to Manage>Identity>BI repository and Click on Applications Role tab. here you can double-click on any application role and set permissions on whole subject area or a particular object of subject area and set appropriate permissions for it. Alternatively you can go to Presentation layer and douvble click on any object and set permissions for it.

At the presentation services layer, you can open the Analytics Link and go to Administration > "Manage Previleges" and set various permissions for different objects. You can also edit properties for individual reports or dashboard and assign privileges here.

Row-Level Permissions means that a group of users have access to reports but each one of them will see different data sets depending on the permission each user is assigned to. To set row-level security, following steps need to be executed:

1. Identity the key information that needs to be filtered and assign it to a user login name. e.g in for Clinical data, if we want to filter the Studies for different users, we have to identify the study numbers allowed for user login names. Store this information in a database table(security table) so that you know know which study numbers belong to which user login.
2. Create a "row-wise initialized" session variable that will store the study numbers for each user that logs in.(We are assuming that 1 user can be assigned to multiple study numbers. Thats why we have to use a row-wise initialized variable). The initialization block query could be of this form:

select 'STUDY_NUMBER', study_number from security_table where login=':USER'. This will create a session variable with name STUDY_NUMBER and assign it a semi-colon separated list of study numbers for the particular user that has logged in.

3. Go to Admin Tool> Manage>Identity and click on Application Tab. Click on the application role where you want to apply row-level filter. If you want to apply filter for all users, select BIConsumer . Click on Permissions and select "Data Filters' tab. Click Add button and select the table(either from Presentation or Business Model layer) on which you want to apply the filter. The value of the filter should be as follows:

"Table Name".Study Number = VALUEOF(NQ_SESSION.STUDY_NUMBER)

Alternatively, you could also go to the Business Model Layer and select the logical table source of the table(Content tab), you wish to apply the filter on and give the filter expression as above in the WHERE clause.