About

This chapter discusses about object level security which is set at web catalog level on folders, dashboards, dashboard pages and reports.

1. Verify Security Settings

To make policy store changes visible throughout Oracle BI, you must restart Oracle BI Server.

In this example, JCRUZ has logged into Oracle BI and selected My Account. On the Roles and Catalog Groups tab, he sees all the roles to which he is assigned.

Jose Cruz is a member of the Sales Managers Group and Sales Supervisors group. Because both of these roles are members of the Sales Associates Role application role, he is also a member of the role. By default, all BI users are also the members of the default application roles, Authenticated User and BI Consumer Role.

The value of using application roles comes from the fact that you can move the system you have built between environments without having to rewire all of the security. For example, you would not have to change the security settings in your presentation catalog or repository. You can just remap your application roles to the target environment.

After you restart Oracle BI Server, changes in security settings are visible in the Identity manager in the repository.

2. Set up Object Permissions

The Object Permissions are set by using the Admin tool. There are two approaches for setting the Object permissions.

• You can set the permissions for particular users or application roles in the Identity Manager if you want to define permission for larger set of objects at one time.

• Permissions can be set for individual objects in the presentation layer.

In this example, permissions are set for the Customer presentation table object. Access to this object is restricted for the AuthenticatedUser, BIConsumer, SalesAssociateRole application roles. The user AZIFF is a member of these application roles. Therefore, AZIFF does not have access to the Customer presentation table when he logs into Oracle BI and selects the SupplierSales subject area.

3. Permission Inheritance

Users can have explicitly granted permissions. They can also have permissions granted through membership in application roles, which in turn can have permissions granted through membership in other application roles, and so on.

• Permissions granted explicitly to user take precedence over privileges granted through application roles.

• Permissions granted explicitly to application role take precedence over any privileges granted through other application roles.

• If Security attributes conflict at the same level, a user or application role is granted the least-restrictive security attribute.

Example:

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

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

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

4. Set Row Level Security (Data filters)

Data filters are a security feature that provides a way to enforce row-level security rules in the repository. Data filters can be set of objects in both the BMM layer and the Presentation Layer. Applying a filter on a logical object affects all Presentation layer objects that use the object.

In this example, you set a filter on the Customer presentation table for the SalesSupervisorsRole application role so that the customer data is visible for only those records in which JoseCruz or his direct reports are the Sales representatives. After setting this filter, if Jose Cruz creates and runs an analysis that includes the SalesRep column, only his records and those of his direct report are visible.

5. Set the Query Limits

Oracle BI Server prevents queries from consuming too many resources by limiting how long a query can run and how many rows a query can retrieve.

To access the Query Limits tab, open the Identity Manager, click the Application Roles tab, double-click an application role to open the Application Role dialog box, and click Permissions.

Use the Query Limits tab to:

• Limit queries by maximum run time or to time periods for a user or role.

• Control the number of rows accessed by a user or role.

• Control the maximum query run time.

• Enable or disable Populate Privilege.

• Enable or disable Execute Direct Database Requests

Note:

It is a recommended practice to set query limits for application roles rather than for individual users.

6. Set Timing Restrictions

You can regulate when users can query databases to prevent users from querying when system resources are tied up with batch reporting, table updates, or other production tasks.

To restrict access to a database during particular time periods, click the ellipsis (...) button in the Restrict column to open the Restrictions dialog box. Then perform the following steps:

1. To select a time period, click the start time and drag it to the end time.

2. To explicitly disallow access, click Disallow.

7. Cache Management

1. Business Challenge

Decision support systems require a large amount of database processing.

Frequent trips to back-end databases to satisfy query requests can result in increased query response time and Poor Performance.

Selvi

Add comment