Select Manage, then select Identity. In the Identity Manager dialog, in the tree pane, select BI Repository. In the Application Role dialog, click Permissions. Click OK, then click OK again to return to the Identity Manager.

Applying Data Access Security to Repository Objects 13-9 Figure 13–4 Object Permission Enforcement in the Oracle BI Server Note the following: ■ If an application role is granted or disallowed 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 are implicitly denying access to all of the logical columns associated with that table. ■ Object permissions do not apply to repository and session variables, so values in these variables are not secure. Anybody who knows or can guess the name of the variable can use it in an expression in Answers or in a Logical SQL query. Because of this, do not put sensitive data like passwords in session or repository variables. ■ You can control what level of privilege is granted by default to users and application roles for repository objects without explicit permissions set. To do this, set the DEFAULT_PRIVILEGES parameter in the NQSConfig.INI file. See Oracle Fusion Middleware System Administrators Guide for Oracle Business Intelligence Enterprise Edition for more information. To set up object permissions for individual application roles: 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. Note that if you are in offline mode, no application roles appear in the list unless you have first modified them in online mode. See About Applying Data Access Security in Offline Mode for more information.

5. In the Application Role dialog, click Permissions.

13-10 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition 6. In the UserApplication Role Permissions dialog, in the Object Permissions tab, select an object by performing one of the following steps: ■ Click the Add button. Then, browse to locate the object you want, select it, and then click Select. ■ Click the Name field for an empty row. Then, browse to locate the object you want, select it, 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. ■ ReadWrite: 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, and so on. 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, the user or application role is granted the least restrictive security attribute. Any explicit permissions acting on a user take precedence over any permissions on the same objects granted to that user through application roles. 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. Note that you should always define object permissions for application roles rather than for individual users. Example 13–1 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, as shown in Figure 13–5 . Because permissions granted directly to the user take precedence over those granted through application roles, User1 has the permission to read TableA. Applying Data Access Security to Repository Objects 13-11 Figure 13–5 User Permissions and Application Role Permissions Example 13–2 Permission Inheritance 2 Consider the situation shown in Figure 13–6 . Figure 13–6 Permissions Example 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. 13-12 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition Setting Query Limits You can manage the query environment by setting query limits governors in the repository for particular application roles. You can limit queries by the number of rows received, by maximum run time, and by restricting to particular time periods. You can also allow or disallow direct database requests or the Populate privilege. You should always set query limits for particular application roles rather than for individual users. This section contains the following topics: ■ Accessing the Query Limits Functionality in the Administration Tool ■ Limiting Queries By the Number of Rows Received ■ Limiting Queries By Maximum Run Time and Restricting to Particular Time Periods ■ Allowing or Disallowing Direct Database Requests ■ Allowing or Disallowing the Populate Privilege Accessing the Query Limits Functionality in the Administration Tool Follow the steps in this section to access the Query Limits tab of the UserApplication Role Permissions dialog. To access the query limits functionality in the Administration Tool for a particular application role: 1. Open your repository in the Administration Tool.

2. Select Manage, then select Identity.