Setting Up Object Permissions

Use these steps to set up object permissions for individual application roles in your repository to control access to Presentation layer and Business Model and Mapping layer objects.

Application roles are not displayed if you are using offline mode unless you have first modified them in online mode. See About Applying Data Access Security in Offline Mode.

  1. Open your repository in the Administration Tool.
  2. Select Manage, then select Identity.
  3. In the Identity Manager dialog, in the tree pane, select BI Repository.
  4. In the right pane, select the Application Roles tab, then double-click the application role for which you want to set object permissions.
  5. In the Application Role dialog, click Permissions.
  6. In the User/Application Role Permissions dialog, in the Object Permissions tab, do one of the following to select an object:
    • Click the Add button, locate the object, and then click Select.
    • Click the Name field in an empty row, locate the object, and then click Select
  7. Assign the appropriate permission for each object. You can choose one of the following options:
    • Read: Only allows read access to this object.
    • Read/Write: Provides both read and write access to this object.
    • No Access: Explicitly denies all access to this object.
  8. Click OK, then click OK again to return to the Identity Manager.

About Permission Inheritance for Users and Application Roles

Users can have explicitly granted permissions. They can also have permissions granted through membership in application roles, that in turn can have permissions granted through membership in other application roles.

Permissions granted explicitly to a user have precedence over permissions granted through application roles, and permissions granted explicitly to the application role take precedence over any permissions granted through other application roles.

If there are multiple application roles acting on a user or application role at the same level with conflicting security attributes, then the user or application role is granted the least restrictive security attribute. Oracle currently requires that the application role with access to an object also have access to the object's container. For example, if ApplicationRole 1 has permission to access Column A, which is part of Table B, then ApplicationRole1 must also have permission to access Table B. Any explicit permissions acting on a user take precedence over any permissions on the same objects granted to that user through application roles.

In previous releases, the application role did not require access to an object's container, as described above. To revert to this behavior, go to the Oracle BI Server machine and create environment variable OBIS_SECURITY_10g_COMPATIBLE and set it to 1.

Filter definitions, however, are always inherited. For example, if User1 is a member of Role1 and Role2, and Role1 includes a filter definition but Role2 does not, the user inherits the filter definition defined in Role1.

You should always define object permissions for application roles rather than for individual users.

Description of GUID-495F4979-86CB-481F-A061-2462D3B1EF60-default.gif follows
Description of the illustration GUID-495F4979-86CB-481F-A061-2462D3B1EF60-default.gif
Description of GUID-7822C7C1-8DCD-46FE-8990-42C88D31C92F-default.gif follows
Description of the illustration GUID-7822C7C1-8DCD-46FE-8990-42C88D31C92F-default.gif

These are the resulting permissions:

  • User1 is a direct member of Role1 and Role2, and is an indirect member of Role3, Role4, and Role5.

  • Because Role5 is at a lower level of precedence than Role2, its denial of access to TableA is overridden by the READ permission granted through Role2. The result is that Role2 provides READ permission on TableA.

  • The resultant permissions from Role1 are NO ACCESS for TableA, READ for TableB, and READ for TableC.

  • Because Role1 and Role2 have the same level of precedence and because the permissions in each cancel the other out (Role1 denies access to TableA, Role2 allows access to TableA), the less restrictive level is inherited by User1. In other words, User1 has READ access to TableA.

  • The total permissions granted to User1 are READ access for TableA, TableB, and TableC.

Permission Inheritance 1

You might have a user (User1) who is explicitly granted permission to read a given table (TableA). Suppose also that User1 is a member of Role1, and Role1 explicitly denies access to TableA. The resultant permission for User1 is to read TableA.

Because permissions granted directly to the user take precedence over those granted through application roles, User1 has the permission to read TableA.