Determining a User's Privileges and Permissions in Presentation Services

Presentation Services privileges and 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.

When you try to access functionality in Presentation Services, the appropriate privilege is checked; for example, to view the Oracle Analytics Server 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 Analytics Server, the item's permissions are checked to see if you have read access.

The types of records that you may add 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.

• Application roles records

  This is the recommended way of managing ACLs.

Oracle Analytics Server determines user access by sequentially checking the 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's one); 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

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:

Each earlier step takes precedence over any later step.

Note:

Within an individual step, a privilege access control (ACL) record that's Denied always takes precedence over any other grants. Within an individual step, a permission ACL record that has No Access always takes precedence over any access grant.

The privilege Denied is the same as the permission No Access. The term deny is 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's an explicit record for this user, then return that access, Done.
2. If there's no explicit record for this user. Go to Step 2.

Task 2 - 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 3.

Task 3 - Fall back default behavior

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

Note:

The Authenticated User application role is deliberately not included in the list of application roles for a user in Task 2, even though that user does technically have this application role.

1. If there's a record for the authenticated user application role, return that record's access. Done.
2. Else there's no record for the special application role. Go to Task 4.

Task 4 - 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 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 inherit_priv-oac.png

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 inherit_perm.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. The 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. The 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.