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