1. Managing Metadata Repositories for Oracle Analytics Server
  2. Build Your Metadata Repository
  3. Apply Data Access Security to Repository Objects
  4. Object Permissions

Object Permissions

You can set up object permissions in your repository to control access to Presentation layer and Business Model and Mapping layer objects

You set object permissions using the Model Administration Tool.

To set up object permissions:

  • Set the data access for specific application roles.

  • Specify functional groups when multiple application roles have different levels of access to the same object.

  • Select individual objects in the Presentation layer.

Set up object permissions for application roles when you want to define data access permissions for a set of objects that are common to users assigned the specific application role. You should set up object permissions for specific application roles rather than for individual users to simplify data access management.

The following image shows how object permissions can restrict users from viewing specific repository object. Security rules are applied to all incoming client queries, and can't be breached, even when the Logical SQL query is modified. In this example, the Administrator application role has been granted access to the Booked Amount column allowing the Administrator to view the returned results. The user, Anne Green, who isn't a member of an application role with access to the Booked Amount column, can't see the column in the Subject Area pane of Answers . Even if the query is modified, results aren't returned for the Booked Amount column because of the application role-based object permissions have been set.

Description of data_sec_3.gif follows
Description of the illustration data_sec_3.gif

  • If an application role has permissions on an object from multiple sources, for example, explicitly and through one or more additional application roles, the permissions are applied based on the order of precedence.

  • If you explicitly deny access to an object that has child objects, users who are members of the individual application role are denied access to the child objects. For example, if you explicitly deny access to a particular logical table, you're implicitly denying access to all of the logical columns associated with that table.

  • Object permissions don't apply to repository and session variables, so values in these variables aren't secure. Anyone who knows or can guess the name of the variable can use it in an expression in Answers or in a Logical SQL query. Don't put sensitive data like passwords in session or repository variables.

  • You can control the level of privilege is granted by default to the AuthenticatedUser application role. The AuthenticatedUser is the default application role associated with new repository objects.

    The AuthenticatedUser application role means any authenticated user. The AuthenticatedUser application role is internal to the Oracle BI Repository. The AuthenticatedUser application role appears in the Permissions dialog for connection pools and Presentation layer objects. The AuthenticatedUser doesn't appear in the list of application roles in the Identity Manager.

    Update the DEFAULT_PRIVILEGES parameter in the NQSConfig.INI file. See Security Section Parameters in Administering Oracle Analytics Server.

Set 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 aren't displayed if you're using offline mode unless you've first modified them in online mode. See About Applying Data Access Security in Offline Mode.

  1. Open your repository in the Model 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 didn't 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 doesn't, 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 inheritance1.gif follows
Description of the illustration inheritance1.gif
Description of inheritance2.gif follows
Description of the illustration inheritance2.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.