Determining a User's Privileges and Permissions in Oracle BI Presentation Services

Oracle BI Presentation Services privileges and Oracle BI Presentation Services Catalog item permissions, use an Access Control List (ACL) to control who has privilege to access Presentation Services functionality and what permissions any given user can have on Presentation Services Catalog items. Privileges are set using the Administration pages in Oracle BI Presentation Services. Permissions are set for Presentation Services Catalog objects through the Analytics user interface, or the Catalog Manager user interface.

When you try to access functionality in Presentation Services, the appropriate privilege is checked; for example, to view the Oracle Business Intelligence page you must have the Access to Answers privilege. Also, when you try to perform any action on a Presentation Services Catalog item, that item's permissions are checked; for example, to view an item in Oracle Business Intelligence, the item's permissions are checked to see if you have read access.

There are 3 types of records that may be added to an ACL:

• Individual user records

  It is difficult to administer individual user records especially when there might be thousands of users, and hundreds of thousands of Catalog items.

• 10g Catalog group records

  Catalog groups exist purely for backwards compatibility, and are not recommended. They should not be used, instead you should change to using application roles.

• 11g application roles records

  These are the recommended way of managing ACLs.

Oracle Business Intelligence determines user access by sequentially checking 3 types of records. A user's effective privileges or permissions are deduced using the ACL records, looking for an explicit record for the user (if there is one); then looking for any records with the Catalog groups, of which the user is directly and indirectly a member; and then looking for any records with application roles granted to the user either explicitly or implicitly.

This section contains the following topics:

• Rules for Determining a User's Privileges or Permissions

• Example of Determining a User's Privileges with Application Roles

• Example of Determining a User's Permissions with Application Roles

• Example of Determining a User's Privileges with Removed Catalog Groups

• Example of Determining a User's Permissions with Removed Catalog Groups

Rules for Determining a User's Privileges or Permissions

The following tasks describe the sequential checks completed to determine a user's effective privileges and permissions.

Note:

Step 1 takes precedence over Step 2, which takes precedence over Step 3, which takes precedence over Step 4, which takes precedence over Step 5.

Note:

Within an individual step, a privilege ACL record that is Denied always takes precedence over any other grants. Similarly, within an individual step, a permission ACL record that has No Access always takes precedence over any access grant.

Semantically, the privilege Denied is the same as the permission No Access, and so the term deny will be used interchangeably for both privileges and permissions.

Task 1 - Check for an explicit record for this user

The following sequence represents the checks completed for a user record.

1. If there is an explicit record for this user, then return that access. Done.
2. If there is no explicit record for this user. Go to Task 2 - Check for records for this user's Catalog groups (removed behavior for 10g backwards compatibility only).

Task 2 - Check for records for this user's Catalog groups (removed behavior for 10g backwards compatibility only)

The following sequence represents the checks completed for a user's Catalog groups.

1. Get the set of all Catalog groups this user is directly, explicitly in.

   This set does not include Catalog groups that this user is implicitly in.

   This set includes:

   • Catalog groups assigned through the Presentation Services Administration Page.

   • Catalog groups assigned through the WEBGROUPS BI session variable.

   • Any Catalog group that has an application role as a member, where that application role has been granted (either explicitly or implicitly) to this user.

     Note:

     This functionality was initially provided to help migration of 10g Catalog groups to 11g application roles, rather than force immediate conversion of all Catalog groups to application roles.

2. Check for any ACL record that matches any of the current set of Catalog groups as follows:

   • If there are any records that deny access, then return access denied. Done.

   • Else, if there are any records that grant access, return the union of all those access grants. For example, if one Catalog group has read access, and another Catalog group has write access, then the user has read and write access. Done.

   • Else, no records matched the current set of Catalog groups.

3. Get the parent set of all Catalog groups of the current set of Catalog groups. In other words, get all Catalog groups that the current set of Catalog groups are themselves members of explicitly. This parent set becomes the new current set of Catalog groups.
4. If the parent set is not empty, go to "Step 2".

   • Thus, explicit Catalog groups take precedence over (override) implicit Catalog groups.

   • Similarly, implicit "parent" Catalog groups take precedence over implicit "grandparent" Catalog groups; implicit "grandparent" Catalog groups take precedence over implicit "great-grandparent" Catalog groups; and so on.

     Note:

     The logic for permission inheritance for Catalog groups is different to the logic for permission inheritance for application roles.

5. Else there were no records for this user's Catalog groups. Go to Task 3 - Check records for this user's application roles.

Task 3 - Check records for this user's application roles

The following sequence represents the checks completed for a user's application roles.

1. Get all the application roles for this user, including both direct, explicit application roles and indirect, implicit application roles.

   For example, if a user is explicitly granted the BI Author application role, then the user also implicitly has the BI Consumer application role too.

2. Check for any ACL record that matches any of the set of application roles.

   • If any records deny access, then return access denied. Done.

   • Else, if any records grant access, return the union of all those access grants. So if one application role had read access, and another application role had write access, then the user has read and write access. Done.

   • Else there are no records for this user's application roles.

3. Else there were no records for this user's application roles. Go to Task 4 - Fall back default behavior.

Task 4 - Fall back default behavior

The following sequence represents the checks completed for a specific application role called Authenticated User.

1. If there is a record for the authenticated user application role, return that record's access. Done.

   Note:

   The Authenticated User application role is deliberately not included in the list of application roles for a user in Task 3 - Check records for this user's application roles, even though that user does technically have this application role too.

2. Else there is no record for the special application role. Go to Task 5 - No matching records at all.

Task 5 - No matching records at all

Return access denied. Done.

Example of Determining a User's Privileges with Application Roles

The diagram shows an example of how privileges are determined with application roles.

At the top of the diagram is a rectangle labelled User1, which specifies that User1 has been explicitly given the application roles Executive and BI Author. Attached beneath the User1 rectangle are two more rectangles - one on the left that represents the Executive role and one on the right that represents the BI Author role.

• The Executive role rectangle specifies that Executive is granted the Access to Administration privilege, and that the application roles Finance and Sales have in turn been given to Executive.

• The BI Author role rectangle specifies that BI Author is granted the Catalog privilege, is Denied the Agents privilege, and that the application role BI Consumer has in turn been given to BI Author.

Attached beneath the Executive Role rectangle are two more rectangles - one on the left that represents the Finance role and one on the right that represents the Sales role:

• The Finance Role rectangle specifies that the Finance role is granted the Scorecard privilege.

• The Sales Role rectangle specifies that Sales is Denied the Access to Administration privilege and granted the Access to Answers privilege.

And finally, attached beneath the BI Author Role rectangle is a rectangle that represents the BI Consumer role:

• The BI Consumer Role rectangle specifies that BI Consumer is granted the Catalog privilege and is granted the Agents privilege.

Description of the illustration GUID-06E92BB8-387B-4562-84D6-DEF33843B8F5-default.gif

In this example:

• 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.

• So 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, granted Scorecard privilege, and granted Answers privilege. The Sales' Denied Administration privilege takes precedence over Executive's granted privilege, as Deny always takes precedence.

• The effective privileges from the BI Author role are granted Catalog privilege, and Denied Agents privilege. The BI Author's Denied Agents privilege takes precedence over BI Consumer's granted, as deny always takes precedence.

The total privileges granted to User1 are as follows:

• Denied Administration privilege, because the privilege is specifically denied for Sales.

• Granted Scorecard privilege.

• Granted Answers privilege.

• Granted Catalog privilege.

• Denied Agents privilege, because the privilege is specifically denied for BI Author.

Example of Determining a User's Permissions with Application Roles

The diagram below shows an example of how permissions are determined with application roles.

At the top of the diagram is a rectangle labelled User1, which specifies that User1 has been explicitly given the application roles Executive and BI Author. Attached beneath the User1 rectangle are two more rectangles - one on the left that represents Executive Role and one on the right that represents BI Author Role.

• The Executive Role rectangle specifies that Executive has no access to DashboardA, and that the application roles Finance and Sales have in turn been given to Executive.

• The BI Author Role rectangle specifies that BI Author role has open access to DashboardD, has no access to DashboardE, and that the BI Consumer role has in turn been given to BI Author.

Attached beneath the Executive Role rectangle are two more rectangles - one on the left that represents Finance role and one on the right that represents Sales role:

• The Finance Role rectangle specifies that Finance role has open access to DashboardB.

• The Sales Role rectangle specifies that Sales role has no access to DashboardA and full control of DashboardC.

And finally, attached beneath the BI Author Role rectangle is a rectangle that represents BI Consumer role:

• The BI Consumer Role rectangle specifies that BI Consumer role has modify access to DashboardD and open access to DashboardE.

Description of the illustration GUID-9F975935-9584-480B-8849-0EB7039560CF-default.gif

In this example:

• User1 explicitly has Executive role, and thus implicitly has Finance role and also Sales role.

• User1 also explicitly has BI Author role, and thus also implicitly has BI Consumer role.

• So User1's flattened list of application roles is Executive, BI Author, Finance, Sales and BI Consumer.

• The effective permissions from Executive role are no access to DashboardA, open access to DashboardB, and full control for DashboardC. Note Sales role's No Access to DashboardA takes precedence over Executive role's Open, as Deny always takes precedence.

• The effective privileges from BI Author role are Open&Modify access to DashboardD, and No Access to DashboardE. Note BI Author role's No Access to DashboardE takes precedence over BI Consumer role's Open, as Deny always takes precedence.

The total permissions and privileges granted to User1 are as follows:

• No Access to DashboardA, because access is specifically denied for Sales role.

• Open Access to DashboardB.

• Full Control for DashboardC.

• Open&Modify access to DashboardD, the union of Role2's and Role5's access.

• No Access to DashboardE, because access is specifically denied for BI Author role.

Example of Determining a User's Privileges with Removed Catalog Groups

The diagram shows an example of how privileges are determined with Catalog groups.

At the top of the diagram is a rectangle labelled User1, which specifies that User1 is an explicit member of the Catalog groups, Manager Group and Canada Group. Attached beneath the User1 rectangle are two more rectangles - one on the left that represents Manager Group and one on the right that represents Canada Group.

• The Manager Group rectangle specifies that Manager Group is granted the Access to Administration privilege, and that the Manager Group is in turn itself a member of both Marketing Group and Sales Group.

• The Canada Group rectangle specifies that Canada Group is granted the Catalog privilege, is denied the Agents privilege, and that the Canada Group is in turn itself a member of the Americas Group.

Attached beneath the Manager Group rectangle are two more rectangles - one on the left that represents Marketing Group and one on the right that represents Sales Group:

• The Marketing Group rectangle specifies that Marketing Group is granted the Scorecard privilege.

• The Sales Group rectangle specifies that Sales Group is denied the Access to Administration privilege and granted the Access to Answers privilege.

And finally, attached beneath the Canada Group rectangle is a rectangle that represents the Americas Group:

• The Americas Group rectangle specifies that Americas Group is granted the Catalog privilege and is granted the Agents privilege.

Description of the illustration GUID-24C1325B-4103-4466-9E7C-9D40E1A03EEB-default.gif

In this example:

• User1 is explicitly in the Manager Group, and thus is implicitly in the Marketing Group and Sales Group too.

• User1 also is explicitly in the Canada Group, and thus is also implicitly in the Americas Group too.

• So User1's initial list of Catalog groups is Manager Group and Canada Group. If required, User1's parent list of Catalog groups is Marketing Group, Sales Group and Americas Group. The grandparent list of Catalog groups is empty, as the Catalog group hierarchy is only two levels deep.

• The effective privileges from the Manager Group are granted the Administration privilege, granted Scorecard privilege, and granted the Answers privilege. Note explicit Manager Group's record for Administration takes precedence over implicit Sale Group's record, as the more immediate ancestor Catalog group always takes precedence over more distant ancestor Catalog group.

• The effective privileges from the Canada group are granted the Catalog privilege, and denied Agents privilege. Note explicit Canada Group's records for both Catalog and Agents takes precedence over implicit Americas Group's records, as the more immediate ancestor Catalog group always takes precedence over more distant ancestor Catalog group.

The total privileges granted to User1 are as follows:

• Granted Access to Administration privilege, because the Manager Group takes precedence over Sales group.

• Granted Scorecard privilege.

• Granted Answers privilege.

• Granted Catalog privilege, because Canada Group takes precedence over Americas Group.

• Denied Agents privilege, because the Canada Group takes precedence over Americas.

Example of Determining a User's Permissions with Removed Catalog Groups

The diagram below shows an example of how permissions are determined with removed Catalog groups.

At the top of the diagram is a rectangle labelled User1, which specifies that User1 is an explicit member of Catalog groups Manager Group and Canada Group. Attached beneath the User1 rectangle are two more rectangles - one on the left that represents Manager Group and one on the right that represents Canada Group.

• The Manager Group rectangle specifies that Manager Group has open access to DashboardA, and that the Manager Group is in turn itself a member of both Marketing Group and Sales Group.

• The Canada Group rectangle specifies that Canada Group has open access to DashboardD, has no access to DashboardE, and that the Canada Group is in turn itself a member of the Americas Group.

Attached beneath the Manager Group rectangle are two more rectangles - one on the left that represents Marketing Group and one on the right that represents Sales Group:

• The Marketing Group rectangle specifies that Marketing Group has open access to DashboardB.

• The Sales Group rectangle specifies that Sales Group has full control of DashboardC and no access to DashboardA.

And finally, attached beneath the Canada Group rectangle is a rectangle that represents the Americas Group:

• The Americas Group rectangle specifies that Americas Group has Modify access to DashboardD and Open access to DashboardE.

Description of the illustration GUID-609AD307-F056-4356-BD10-7A33A1DFC2ED-default.gif

In this example:

• User1 is explicitly in the Manager Group, and thus is implicitly in the Marketing Group and Sales Group too.

• User1 also is explicitly in the Canada Group, and thus is also implicitly in the Americas Group too.

• So User1's initial list of Catalog groups is Manager Group and Canada Group. If required, User1's parent list of Catalog groups is Marketing Group, Sales Group and Americas Group. The grandparent list of Catalog groups is empty, as the Catalog group hierarchy is only two levels deep.

• The effective permissions from the Manager Group are open access to DashboardA, open access to DashboardB, and full control of DashboardC. Note explicit Manager Group's record for DashboardA takes precedence over implicit Sale Group's record, as the more immediate ancestor Catalog group always takes precedence over more distant ancestor Catalog group.

• The effective permissions from the Canada group are open access to DashboardD, and no access to DashboardE. Note explicit Canada Group's records for both DashboardD and DashboardE takes precedence over implicit Americas Group's records, as the more immediate ancestor Catalog group always takes precedence over more distant ancestor Catalog group.

The total privileges granted to User1 are as follows:

• Open access to DashboardA, because the Manager group takes precedence over Sales group.

• Open access to DashboardB.

• Full control of DashboardC.

• Open access to DashboardD, because the Canada group takes precedence over Americas group.

• No access to DashboardE, because the Canada group takes precedence over Americas group.