BICS: Data Filters and BI Cloud Service Administrators Role

Similar to the on-Premise.rpd File, Data Filters can be configured using the Oracle BICS web modeller. These Data Filters are added to the Analysis to apply a particular data visibility for respective Application Roles. E.g. Users belonging to Application Role “Sales Managers West” should only be able to see data from the West Region, but not middle or East.

Within the web modeller of BICS this can be done using the Data Filters Tab on a Dimension or Fact logical table:


This is similar to OBIEE’s .rpd file, where the Data Filters have been defined also on the Application roles:


Once, the logical Dimension Table is used within an Analysis the defined Data Filter is appended for the defined Application Roles to the Analysis to restrict visibility as row level security.

However, if the User is also a member of the BI Cloud Service Administrators Role then the Data Filters are not applied. Users who are members of this Role are not restricted in terms of data visibility.


Examining OBIEE 11g Presentation Service Privileges and precedence

The Official Documentation for the 11g Oracle Business Intelligence (Security Guide) mentions the following key rules about the evaluation of the Presentation Service Privileges:

“Presentation Services privileges control the rights that users have to access the features and functionality of Presentation Services. Privileges are granted or denied to specific application roles, individual users, and Catalog groups using a privilege assignment table.”

The Presentation Service privileges can be access from the following URL: http://hostname:port/analytics/saw.dll?PrivilegeAdmin


“privileges are either explicitly set or are inherited through role or group membership, explicitly denying a privilege takes precedence over any granted, inherited privilege. Meaning that even if Application roles are nested and thus forming a hierarchy any denied privilege takes precedence over inherited grants or directly assigned grants.”

Additionally, the following example is provided within the D. Appendix section of the same Documentation page:


With the following statements regarding the evaluation:

    • User1 explicitly has the Executive role, and thus implicitly has Finance role and also Sales role.
    • User1 also explicitly has the BI Author role, and thus also implicitly has BI Consumer role.
    • User1’s flattened list of application roles is: Executive, BI Author, Finance, Sales and BI Consumer.

The effective privileges from Executive Role are Denied Administration privilege […] the Sales’ Denied Administration privilege takes precedence over Executive’s granted privilege, as Deny always takes precedence.”

As a showcase, the above has example has been re-created in a simplified version with all Application roles and the Presentation Service privilege for “Access to Administration” within the Oracle BI Version:


The five Application roles of the above diagram have been configured within the Enterprise Manager (EM) Application role configuration:

All five Application roles are also correctly displayed for the User1 within the Oracle Business Intelligence “My Account” view:
Afterwards, the privileges have been configured (with Granted and Denied) for the Application roles within the Presentation Service privileges Administration page:image
However, contrary to the rule and the example the “Administration Page” privilege is not denied:

The “Administration Page” privilege is granted for User1 due to the Membership of the Executive Application Role.

For testing purposes the five Application roles of the example have been enhanced to the following six:


With the following test cases and results:

# User Privilege Executive Finance Sales Sales North Result
1 User1 Admin
Granted / Denied / Granted
2 User1 Admin
/ Denied Granted / Denied
3 User1 Admin
Denied Granted Granted / Denied
4 User1 Admin
/ Granted / Denied Denied
5 User1 Admin Page / Denied / Granted Denied
6 User1 Admin Page / Granted Denied / Denied

deriving the following rules for the determination of the Presentation Service privileges:

  • if a privilege is set (either with denied or granted) for a Application role directly assigned (member of/next) to the User this takes precedence over everything else (see #1+#3)
  • for siblings on the level (within the same hierarchy level) the more restrictive is applied (#2+ #6)
  • In case of inherited ancestor privileges the more restrictive is applied (#4+#5)

Links to the 11g Documentation:

Example of Determining a User’s Privileges with Application Roles

Example of Determining a User’s Privileges with Application Roles

Example of Determining a User’s Privileges with Application Roles

Primary Position/Owner based Security

Oracle BI Applications allow using the same Visibility Concept like Siebel. The following possibilities are supported within the Standard:

  • Primary Position/Owner Security
  • Organisation Security

The following Article focuses on the First Option “Primary Position/Owner Security”. It’s Important to understand a few Basics about Siebel:

  1. A Position defines a specific job Slot within a Company and usually starts with the Position of the CEO, having the CIO,CFO, CTO etc. reporting to him. The next Position e.g. Vice President Sales then Reports to the CFO.
  2. A Position can have a particular Incumbent (or Employee). E.g. “John Smith” is the current Incumbent of the Position Sales Manger West for Automotive. There might be other employees before “John Smith” how aren’t active in this Position anymore
  3. Most Objects in Siebel like Opportunities, Marketing Campaigns etc. are associated to a Position and not the Employee. However, a few Objects which are shorter lasting like Activities, Service Request etc. are associated to an Employee directly.

It is Important to note that the Concept is called Primary Position/Owner based Security. Thus, there is no either or. Depending on the Object either the Position linkeage or the Owner Linkeage will be used and the Position Hierarchy will always be respected even if Objects are linked to Owners. It’s also possible to have two Employees sharing a Position at the same Point in Time, but only the Primary Employee will be able to see the data within the Analytical Application (BI Apps). This is because the Position Hierarchy (W_POSITION_DH) will be used to limit the Visible data based on the Position within the Hierarchy and the Primary Employee is an Attribute of that Position. Thus, it’s not possible to have a many to one Relationship in this Hierarchy, but only one Employee (the Primary) as a Descriptive Attribute of the Position Hierarchy.

E.g. the West Rep1 Position does only have the Primary Incumbent in the Position as a descriptive Attribute to the Position.

This is stored in the W_INT_ORG_DH in the following way:

To Configure the Security correctly one needs to administer the Incumbents within a Position in the following Screens in Siebel CRM:

The following is the Administration Screen to select an Employee within a Position:

The Child Position needs to be configured accordingly:

After setting up the Position Hierarchy and Incumbents in Siebel the Hierarchy will be loaded into the BI Applications data model. Based on the Hierarchy the BI Server will create a Query like the following:

The above Query is for the Position that is located at the top of the Hierarchy. Note that the Login is used to compare to the login, thus the Position Incumbent. Hence, if multiple Employees share the same position only the login (Employee) that is the Primary Employee will have access to the data. Other Employee’s won’t have any!

For the Position that is located below the following Query will be created:

And for the Position below:

And for the Position that is located at the very bottom, the Base Position will be used:

All of this is steered through the Position Security Hierarchy within the Business Model Layer of the BI Admin Tool (.rpd) using the INDEXCOL Function on the “Dim – Position Security” Dimension.

"Core"."Dim - Position Security"."Current Base Level Login", 
"Core"."Dim - Position Security"."Current Level 1 Login", 
"Core"."Dim - Position Security"."Current Level 2 Login", 
"Core"."Dim - Position Security"."Current Level 3 Login", 
"Core"."Dim - Position Security"."Current Level 4 Login", 
"Core"."Dim - Position Security"."Current Level 5 Login", 
"Core"."Dim - Position Security"."Current Level 6 Login", 
"Core"."Dim - Position Security"."Current Level 7 Login", 
"Core"."Dim - Position Security"."Current Level 8 Login", 
"Core"."Dim - Position Security"."Current Level 9 Login", 
"Core"."Dim - Position Security"."Current Level 10 Login", 
"Core"."Dim - Position Security"."Current Level 11 Login", 
"Core"."Dim - Position Security"."Current Level 12 Login", 
"Core"."Dim - Position Security"."Current Level 13 Login", 
"Core"."Dim - Position Security"."Current Level 14 Login", 
"Core"."Dim - Position Security"."Current Level 15 Login", 
"Core"."Dim - Position Security"."Current Level 16 Login", 
"Core"."Dim - Position Security"."Current Top Level Login")

This Function uses the Session Variable “HIER_LEVEL” which determines the Level one Particular Employees is in to steer the correct Data Visibility. This Session Variable is Initialized using the following Authorization Block:

This means that one Employee can see always “his” correct data even for Objects which are linked to positions e.g. like Opportunities.