Working with Groups

The Oracle BI Server allows you to create groups and then grant membership in them to users or other groups.

You can think of a group as a set of security attributes. The Oracle BI Server groups are similar to groups in Windows NT and Windows 2000, and to groups or roles in database management systems (DBMS). Like Windows NT and Windows 2000, and database groups or roles, Oracle BI Server groups can allow access to objects. Additionally, Oracle BI Server groups can explicitly deny particular security attributes to its members.

Groups can simplify administration of large numbers of users. You can grant or deny sets of privileges to a group and then assign membership in that group to individual users. Any subsequent modifications to that group will affect all users who belong to it. Externally defined users can be granted group membership by use of the GROUP session variable. For more information about session variables, refer to Using System Session Variables.

This section includes the following topics:

• Predefined Administrators Group
• Defined Groups
• Group Inheritance
• Adding a New Group
• Viewing Member Hierarchies

Predefined Administrators Group

The Oracle BI Server has one predefined group, the Oracle BI Administrators group. Members of this group have the authority to access and modify any object in a repository. The predefined Oracle BI Administrator user ID is automatically a member of the Oracle BI Administrators group.

Use caution in granting membership in the Oracle BI Administrators group to users or other groups. Membership in the Oracle BI Administrators group supersedes all privileges granted to a user, either through groups or explicitly through the user privileges. Any user who is a member of the Oracle BI Administrators group has all of the privileges of the Oracle BI Administrator user.

Defined Groups

You can create an unlimited number of groups in an Oracle BI repository. Each group can contain explicitly granted privileges or privileges granted implicitly using membership in another group. For more information about setting up a group, refer to Adding a New Group.

For example, you can create one group that denies access to the repository on Mondays and Wednesdays (Group1), another group that denies access on Saturdays and Sundays (Group2), and another that denies access on Tuesdays, Thursdays, and Fridays (Group3). Users who are members of Group2 can access the system only during weekdays, users who are members of Group1 and Group3 can access the system only on weekends, and so on.

Group Inheritance

Users can have explicitly granted privileges. They can also have privileges granted through membership in groups, that in turn can have privileges granted through membership in other groups, and so on. Privileges granted explicitly to a user have precedence over privileges granted through groups, and privileges granted explicitly to the group take precedence over any privileges granted through other groups.

If there are multiple groups acting on a user or group at the same level with conflicting security attributes, the user or group is granted the least restrictive security attribute. Any explicit permissions acting on a user take precedence over any privileges on the same objects granted to that user through groups.

Example 1

Suppose you have a user (User1) who is explicitly granted permission to read a given table (TableA). Suppose also that User1 is a member of Group1, that explicitly denies access to TableA. The resultant privilege for User1 is to read TableA, as shown in Figure 21.

Because privileges granted directly to the user take precedence over those granted through groups, User1 has the privilege to read TableA.

Figure 21. User Privileges and Group Privileges

Example 2

Consider the situation shown in Figure 22.

Figure 22. Privileges Example

These are the resulting privileges:

• User1 is a direct member of Group1 and Group2, and is an indirect member of Group3, Group4, and Group5.
• Because Group5 is at a lower level of precedence than Group2, its denial of access to TableA is overridden by the READ privilege granted through Group2. The result is that Group2 provides READ privilege on TableA.
• The resultant privileges from Group1 are DENY for TableA, READ for TableB, and READ for TableC.
• Because Group1 and Group2 have the same level of precedence and because the privileges in each cancel the other out (Group1 denies access to TableA, Group2 allows access to TableA), the less restrictive level is inherited by User1; that is, User1 has READ access to TableA.
• The total privileges granted to User1 are READ access for TableA, TableB, and TableC.

Adding a New Group

The following procedure explains how to add a new group to a repository.

To add a new group to a repository

1. Open a repository in the Administration Tool. (The repository can be opened in either online or offline mode.)
2. Display the security window by selecting Manage > Security.
3. Select Action > New > Group from menu.
   The Group dialog box appears.
   NOTE:  You can also select the Group icon in the left pane, and then right-click on white space in the left pane and select New Security Group from the right-click menu.
4. Type a name for the group and click OK.
   This creates a new group with no rights granted to it.
5. To modify the group's permissions, open the Group dialog by double-clicking on the group icon you want to modify. If you click on Permissions, you can change permissions for multiple columns.
6. You can grant rights to the group by adding other groups, by explicit configuration for the group, or a combination of the two. To grant membership to a group, click Add and select any users or groups you want to grant membership. Click OK after you have selected the groups and users.
7. Set up any query permissions for the group. For information, refer to Managing Query Execution Privileges.
   NOTE:  Unlike the User dialog box, the Group dialog box does not allow you to select a logging level. The logging level is a user attribute and cannot be specified for a group.

Viewing Member Hierarchies

Use the following procedures to view member hierarchies.

To view member hierarchies in the Security Manager

• Click the hierarchy icon in the left pane of the Security Manager, and then expand the tree in the right pane.

To view member hierarchies in the Query Repository dialog box

1. Select Tools > Query Repository from the main menu of the Administration Tool.
2. To view all groups, select Security Groups from the Type drop-down list and click Query.
3. To view all users, select Users from the Type drop-down and click Query.
4. To view the groups that a group is a member of, select the group and click Parent. For example, to view what groups Group1 is a member of, select Group1 and click the Parent button.