Member-level security

Member-level security enables report designers to limit user access to the specific members of dimensions in business/report cubes or of groups in business views.

Permissions logic

The relationship between a user/role/group and the members of a dimension/group are classified into these groups:

• Allowed Set
  The members of a dimension/group visible to a user/role/group, which are directly specified in the user/role/group, excluding those inherited from the parent roles or groups.
• Denied Set
  The members of a dimension/group invisible to a user/role/group, which are directly specified in the user/role/group, excluding those inherited from the parent roles or groups.
• Unspecified members
  The members of a dimension/group that are not specified in a user's allowed/denied Set or in the inherited allowed/denied set from the user's parent roles/groups. The option is available to users only.

A user/role/group can have its own allowed/denied set and inherit the allowed/denied sets from its parent roles or groups. The parent allowed/denied sets will be calculated first and it is a recursive process.

The following are the detailed working logic:

• The directly defined permission on a user/role/group always overwrites the permission inherited from its parents. That is, for a member of a dimension/group, if its permission has not been defined on a given user/role/group, the permission will inherit from the parents of the user/role/group; if it is defined, the permission will be used directly.
• If for a user/role/group a member exists in both the allowed set and denied set, the denied set has higher priority than the allowed set. In this case the member is not available to the user/role/group.
• Inheritance rule:
  • If a member is denied by any of a principal's parents, it will be denied, or else if a member is allowed by any of a principal's parents, it will be allowed.
  • If a member is neither denied nor allowed by any parent, the permission is regarded as unspecified.
• After inheritance rule is applied to a specific user, if some members are still unspecified, the status of the members will depend on the option setting whether to make them allowed or denied.

Here is the priority order:

Denied Set > Allowed Set > Inherited Denied Set > Inherited Allowed Set > Unspecified (no matter whether it is allowed or denied).

See the diagram below:

The final result of the members of a dimension/group that a user/role/group is allowed to access will be:

({Allowed Set} - {Denied Set}) U
(({Inherited Allowed Set from parent 1} U {Inherited Allowed Set from parent 2} U ...) - ({Inherited Denied Set from parent 1} U {Inherited Denied Set from parent 2} U ...)) U
{Unspecified if allowed}

The final set of the unspecified will be:

{All} - ({Allowed Set} U {Denied Set} U {Inherited Allowed Set from parent 1} U {Inherited Denied Set from parent 1} U {Inherited Allowed Set from parent 2} U ...)

For a user, the member-level security in a BC/RC/BV would be like this:

{Accessible members of dimension/group1} And {Accessible members of dimension/group1} And...

Security control

When a catalog with the member-level security is published to the server, only the users/roles/groups on the server which match the principals defined in the member-level security will maintain the member-level security setting. Otherwise, the unmatched will lose the member-level security.

When a user/role/group is deleted from the server security system, the related member-level security setting in all catalogs will be removed.

Examples

Example 1

Here we use a simple sample to describe a case when a user belongs to multiple roles and groups.

Assume there is a dimension Order ID={1,2,3,4,5,6,7,8,9}, and we set member-level security on this dimension for a user (user1) and two roles (role1, role2) separately.

The unspecified members will be {1,2,3,4,5,6,7,8,9} - ({1}U{2,3}U{4,5}U{3,4,5}U{1,2}) = {6,7,8,9}.

Assume we set the property "Whether unspecified members are allowed" to true, which means the unspecified members {6,7,8,9} are allowed to the user.

The final result which user1 can see when only this member-level security is taking effect will be:

{1} U ( ({2,3}U{3,4,5}) - ({4,5}U{1,2}) ) U {6,7,8,9}={1,3,6,7,8,9}

Example 2

This example will be more complex to contain the concepts of four properties of member-level security.

Assume there is a summary table with three groups and summary.

And in below table, we will list the member-level security setting in the left cells of the table, and the final result which a user will get will be listed in the right cells.

Configuring member-level security

1. In the Catalog Browser, do any of the following:
   • Expand the data source > Security node, right-click on Business View Security/Report Cube Security/Business Cube Security and select the edit command on the shortcut menu. The corresponding edit security dialog is displayed.
   • Select a business view or a report/business cube, expand it, then right-click on the Business View Security/Report Cube Security/Business Cube Security node and select the edit command on the shortcut menu. The corresponding edit security dialog is displayed.
   • When creating a business view or a report/business cube, click Tools > Security Configuration on the menu bar. The corresponding edit security dialog is displayed.
   • When adding or editing a business view element or a report/business cube element using dialog, switch to the Security tab.

   See a sample dialog.

   

2. In the User/Group/Role panel, click to add users, roles, and groups manually or by importing from an XML file or from JReport Server.

   To edit a user/role/group, select it and click . In the corresponding edit dialog, edit it as required.

   To delete a user/role/group that is not wanted, select it and click .

3. Make a user/role/group selected.
4. In the Resources box, select the dimension/group field to which you want to set the principal permission.
5. In the Member Level Security box, specify the members of the field in the allowed set or denied set. To do this:
   1. Click above the Specify Allowed Set or Specify Denied Set box. The Edit Values dialog is displayed. See the dialog.

      

   2. Choose a way of specifying the members: select members from the available list, or compose an expression to retrieve members. Only one can be used.
      • To select members, first check the Selected Values radio button.

        If you would like all the possible members of the field to be selected, select <All>.

        If you just want to select some of the members, leave <All> unchecked. Add them one by one by selecting one and then clicking . You can make use of the quick search toolbar to search for the required members.

      • To compose an expression, check the Expression radio button, then click to open the Edit Conditions dialog. See the dialog.

        

        Click the Add Condition button to add a condition line. Choose the operator with which to compose the condition expression from the operator drop-down list. From the value drop-down list, specify the value of how to build the condition. You can also type in the value manually. Click Add Condition to add more condition lines and define the relationship between the condition lines.

        To make some conditions grouped, select them and click the Group button, then the selected conditions will be added in one group and work as one line of filter expression. Conditions and groups together can be further grouped. To take any condition or group in a group out, select it and click Ungroup.

        To adjust the priority of the conditions, select it and click the Up or Down button.

        To delete a condition line, select it and click the Delete button.

   3. Click OK to save the values.
6. Decide whether the unspecified members should be allowed.
7. In the Permission box, specify whether you want the field to be visible to the current principal.
8. Repeat steps 4 to 7 to customize another field's availabilities to the principal.
9. Repeat steps 3 to 7 to customize another principal's accessibility to the members of the dimension/group fields.
10. When finished, click OK in the dialog.
11. Save the catalog. When you save the catalog, the permission settings are also saved and they are saved in an authorization file in the same folder as the catalog file. The catalog and authorization files have the same file name but different extensions, for example, if the catalog file is test.cat, the authorization file will be named test.auth. The authorization file is loaded by the view authorization manager of its catalog during runtime.

See also Edit Business View Security dialog, Edit Values dialog and Edit Conditions dialog for addition information about options in the dialogs.