Previous Page Next Page

Business View Security

Configuring business view security in a catalog

Permission logic on group objects

Example of using business view security

Business view security enables report designers to limit user access to elements of the business views in a catalog. After defining users, groups and roles' permissions on the view elements, when a user accesses a report at runtime that involves the view elements, JReport checks the user, group and role of the user and merges the data in the report the user is authorized to see and displays it to the user, thus different report results can be created for different users. Business view security also applies to new reports end users create on JReport Server using the business views.

Business view security contains two parts:

• Data security
  It controls whether a user/role/group can access the data of the view elements at runtime. For a group object, you can further allow or deny the access of its specific members to a user/role/group.
• Resource security
  It controls whether a user/role/group can see the view elements at runtime.

Business view security, together with the security entries defined in a catalog can be exported to a security file using the File > Export Security command, which will be stored in the same location as the current catalog. The security file can be used to create dynamic security for catalogs on JReport Server (for details, refer to Dynamic Security in the JReport Server User's Guide).

Configuring business view security in a catalog

To define security for the business views in a catalog, take the following steps:

1. Open the required catalog.
2. In the Catalog Manager, do any of the following:
   • Expand the desired data source > Security node, right-click on Business View Security and select Edit Business View Security on the shortcut menu. The Edit Business View Security dialog is displayed.
   • When working with a business view in the Business View Editor, click Menu > Tools > Security Configuration. The Edit Business View Security dialog is displayed.
   • When adding or editing a business view element using dialog, switch to the Security tab.

   The following is a sample dialog.

   

3. In the Users/Groups/Roles panel, click and select Import from JReport Server from the drop-down menu, then in the Connect to JReport Server dialog specify the information to connect to a started JReport Server to import users, roles, and groups from the server. Make sure that you are an administrator user of the started JReport Server in order to perform the importing.

   You can also click and select Add User, Add Role or Add Group from the drop-down menu to add principals manually in JReport Designer or import them from an XML file, however if you choose to add users, groups and roles via these two ways, in order to make the business view security take effect on JReport Server, the users, groups and roles should have been created in the JReport Server security system before the reports involving the business view security are published to JReport Server.

   You can further edit or remove the principals in the User/Group/Role panel.

   • To edit a user/role/group, select it and click . In the corresponding edit dialog, edit it as required. Changes to server users, roles, and groups will not take effect on JReport Server.
   • To delete a user/role/group, select it and click .

   Notes:

   • A user from JReport Server cannot be reassigned to (or removed from) a role from the server. Similarly, a role from the server cannot be re-assigned to (or removed from) a user from the server. So, if both users and roles are obtained from the server, you will not be able to change their parental relationships.
   • You cannot assign a role from the server to a local user created on JReport Designer, while a user from the server can be assigned to a local role.
   • During importing, if any existing users, roles or groups that came from the server have the same names as those on the server, their properties will be refreshed with new information from the server, for example, role, or group information and parental relationships. However, their permission settings will be reserved. Specially, if a user from the server has been assigned to any roles defined in Designer, then these roles will be reserved in its member list.
4. Select one or more users/roles/groups in the principal box. You can use the quick search box to search for the required principals. If you want to select all users, roles or groups at a time, click and then select the corresponding item from the drop-down menu.
5. In the Resources box, select one or more view elements. You can use the quick search box to locate the required ones, or click and select an item from the drop-down menu to select all the detail objects, group objects, aggregation objects, or categories in business views of the current catalog data source at a time.
6. In the Security Options box, uncheck the Use Default option so as to customize the data security and resource security for the selected view elements. If you want to use the default security settings of the selected elements, make the option checked.

   When only one principal and one view element is selected, after you finish defining the data security and resource security, you can save the current security settings as the element's default security settings by clicking the Set as Default button.

7. In the Data Security box, specify whether the selected principals can access values of the selected view elements.
8. In the Resource Security box, specify whether you want the selected view elements to be visible to the principals.
9. If only a group object is selected in step 4, you can further specify which members of the group object are allowed and which are denied for the principals in the Data Security box (for more information, see Permission logic on group objects).
   1. Click above the Allowed Set or Denied Set box. The Edit Values dialog appears.

      

   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 group object 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 search bar to search for the required members.

      • To compose an expression, check the Expression radio button, then click . The Edit Conditions dialog appears.

        

        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.
   4. If users are selected, check whether the unspecified members of the group object are available to the users.

   See Permission logic on group objects for details about the permission logic between allowed set, denied set and unspecified members.

10. Repeat steps 3 to 8 to customize other principals' permissions on the view elements.
11. When finished, click OK in the dialog.
12. 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 for addition information about options in the dialogs.

Permission logic on group objects

The relationship between a principal (user, role or group) and the members of a group object in a business view are classified into three sets:

• Allowed Set
  The members of a group object that a principal is allowed to access, which are directly specified to the principal, excluding those inherited from the parent roles or groups.
• Denied Set
  The members of a group object that a principal is not allowed to access, which are directly specified to the principal, excluding those inherited from the parent roles or groups.
• Unspecified Members
  The members of a group object that are specified neither in a user's allowed/denied set nor in the inherited allowed/denied set from the user's parent roles/groups. Report designer can determine whether a user can access the unspecified members.

A principal 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:

• If for a principal 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 principal.
• The directly defined permission on a principal always overwrites the permission inherited from its parents. That is, for a member of a group object, 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.
• Inheritance rule:
  • If a member is denied by any parent, it will be denied, or else if a member is allowed by any parent, 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 group object that a principal 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 security in a business view would be like this:

{Accessible members of group1} And {Accessible members of group2} And...

We will take some examples to further demonstrate the relationship between a principal and the group object members.

Example 1

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

Assume there is a group object Order ID={1,2,3,4,5,6,7,8,9}, and we set business view security on this group object 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 "Allow Unspecified Members" to true, which means the unspecified members {6,7,8,9} are allowed to the user.

The final result that user1 can see when only this business view 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 is more complex. It contains four properties of the business view security setting.

Assume there is a summary table with three group objects and a summary.

And in below table, we list the business view security setting in the left cells, and the final results a user will get are listed in the right cells.

Example of using business view security

This example is based on the business view WorldWideSalesBV in the SampleReports.cat catalog file. It is assumed that the server administrator has already created two users on JReport Server: User1 and User2, with the passwords abc and xyz respectively. We will create a security policy on SampleReports.cat to limit the two users' access to different group members of WorldWideSalesBV. Before starting the example, make sure JReport Server is started.

The example contains the following tasks:

• Task 1: Set security on business view groups
• Task 2: Create a crosstab and publish it to JReport Server
• Task 3: View the crosstab

Task 1: Set security on business view groups

In this task, we will import the two server users to JReport Designer and limit their access to different members of the Region group in WorldWideSalesBV.

1. Make sure SampleReports.cat is the currently open catalog file. If not click File > Open Catalog to open it from <install_root>\Demo\Reports\SampleReports.
2. In the Catalog Manager, go to the Data Source 1 > Security > Business View Security node, right-click and select Edit Business View Security from the shortcut menu.
3. In the Edit Business View Security dialog, click and select Import from JReport Server.
4. In the Connect to JReport Server dialog, specify the required connection information, then click Connect.

   The principals created on the server will all be imported and listed in the Users/Groups/Roles box.

   

Next, we will assign field members availability to User1 and User2. We will make User1 have access on the North America region only and User2 regions other than North America.

6. Select User1, in the Resources box select Region in WorldWideSalesBV.
7. In the Security Options box, uncheck Use Default.
8. In the Data Security box, allow the Access permission.
9. Click above the Allowed Set box.
10. In the Edit Values dialog, select North America from the Available Values box and click to add it to the Selected Values box, then click OK to close the dialog.

    

11. In the Edit Business View Security dialog, uncheck the option Allow Unspecified Members, then in the Resource Security box, allow the Visible permission.

    

12. Select User2 and the same field Region in WorldWideSalesBV, then uncheck Use Default in the Security Options box.
13. In the Data Security box, allow the Access permission, then click above the Denied Set box.
14. In the Edit Values dialog, select North America from the Available Values box and click , then click OK.
15. In the Resource Security box, allow the Visible permission for User2.

    

16. Click OK in the Edit Business View Security dialog to save the changes.
17. Close the Catalog Manger.

Task 2: Create a crosstab and publish it to JReport Server

In this task, we will create a crosstab using WorldWideSalesBV in the SampleReports catalog and then publish it to JReport Server.

1. In JReport Designer, click File > New > Web Report. A blank web report is created.
2. Click Insert > Crosstab. The Create Crosstab wizard is displayed.
3. In the Data screen, select WorldWideSalesBV under Data Source 1, then click Next.
4. In the Display screen, select Region as the column field, Category as the row field, and Total Sales as the summary field. Click Finish to create the crosstab.

   

5. Click the View tab to preview the crosstab. It shows full data.

   

6. Go back to the design mode and click File > Save to save the crosstab as mlscrstab.wls.

Next, we will publish the crosstab to JReport Server.

7. Click File > Publish > Publish Report to Server.
8. In the Connect to JReport Server dialog, specify the required connection information, then click Connect.
9. In the Publish to JReport Server dialog, unselect the All checkbox and then select the SampleReports.cat and mlscrstab.wls only.
10. Click the Browse button next to the Publish Resource To text box, then in the Select Folder dialog, select Public Reports in the Folder box and click OK.
11. In the Publish to JReport Server dialog, click the More Options button, select mlscrstab.wls in the resource box, then on the right panel, switch to the Permissions tab.

We will grant the two users the necessary permissions on the web report, so that after the report is published to JReport Server, they are able to run them.

12. Select the Enable Setting Permissions checkbox, click the User sub tab, select User1 in the user box and check the Visible and Execute checkboxes; select User2 and do the same.

    

13. Click the OK button to publish the resources to JReport Server.

Task 3: View the crosstab

Now, we can log onto JReport Server as User1 and User2 separately to view the crosstab.

1. Log onto the JReport Server console as User1 with the password abc.
2. Open the Public Reports folder and run the web report mlscrstab.wls. The result will be:

   

3. Log out and then log in again as User2 with the password xyz. Run the report and the result will be:

   

Previous Page Next Page