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

image

“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:

inherit_dl_privscatgrp

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 11.1.1.7 Oracle BI Version:

image

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

image
All five Application roles are also correctly displayed for the User1 within the Oracle Business Intelligence “My Account” view:
image
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:
image

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:

image

With the following test cases and results:

# User Privilege Executive Finance Sales Sales North Result
1 User1 Admin
Page
Granted / Denied / Granted
2 User1 Admin
Page
/ Denied Granted / Denied
3 User1 Admin
Page
Denied Granted Granted / Denied
4 User1 Admin
Page
/ 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 11.1.1.7

Example of Determining a User’s Privileges with Application Roles 11.1.1.9

Example of Determining a User’s Privileges with Application Roles 12.2.1.1

Advertisements

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.

INDEXCOL( VALUEOF(NQ_SESSION."HIER_LEVEL"), 
"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.