Record Level and Column Level Security
Record Level Security (RLS) and Column Level Security (CLS) allow you to control user access to different subsets of data and ensure that people only see what they are supposed to see: RLS allows you to define which records are to be revealed to any given user, while CLS allows you to define which report column is revealed to any given user. This enables you to provide different users with accordingly different, but appropriate contents. No matter to whom you need to provide information, a plant manager or thousands of customers, Logi Report allows you to control access to information according to your requirements.
You can define report level security either based on a catalog data source, or on a single report, or simultaneously on both. When you apply RLS of both the report and data source scopes to a report, the report scope RLS will override that of the data source scope. You can define column level security on data source scope only.
This topic includes the following sections:
- RLS and CLS at Data Source Scope
- RLS at Report Scope
A RLS and CLS policy at data source scope refers to a security entry in the data source of a catalog. It allows you to control user access to different subsets of data, and ensures that people only see what they are supposed to see: certain records and/or report columns. If you want to implement the same security policy in a group of reports, you can simply apply the same security entry to the reports, without having to repeatedly build the security information for each report. The predefined security entries work within a data source range, that is you can apply them to reports that are in the same catalog data source. You can also use a security entry that contains RLS only to control parameter values at runtime.
You can export the security entries, together with the business view security defined in a catalog to a security file using the File > Export Security command. Logi Report Designer saves the security file in the same location as the current catalog by default. The server administrators can then use the security file to create dynamic security for catalogs on Logi Report Server (for details, refer to Dynamic Security in the Logi Report Server Guide).
To add a security entry to a data source in a catalog, follow the steps below:
- Open the required catalog.
- In the Catalog Manager select the data source to which you want to add the security policy.
- Right-click Security Entry under the Security node and then select New Security Entry from the shortcut menu.
- In the Enter Security Name dialog, provide a name for the security policy and select OK. The Security dialog appears.
- In the Users/Groups/Roles panel, select and select Import from Logi Report Server from the drop-down menu, then in the Import from Logi Report Server dialog specify the properties for connecting to a started Logi Report Server to import users, roles, and groups.
Make sure that Logi Report Server has been started and you are an administrator user of the server in order to perform the importing.
You can also select and select Add User, Add Role or Add Group from the drop-down menu to add principals manually in Logi Report Designer or import them from an XML file. However if you choose the two methods to add users, roles and groups, in order for the security policies specified on them to work on Logi Report Server, you should make sure there are the same users, roles and groups created on Logi Report Server, and then import them to Logi Report Designer with the Merge option. In this way the users, roles and groups are updated to those on the server while the security settings are reserved.
You can further edit or remove the principals in the User/Group/Role panel.
- To edit a user/role/group, select it and select . In the corresponding edit dialog, edit it as required. Changes to server users, roles, and groups will not take effect on Logi Report Server.
- To delete a user/role/group, select it and select .
- A user from Logi Report 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. Therefore 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 Logi Report 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 members list.
- Make a user/role/group selected.
- To apply record level security, select the Valid RLS box. To apply column level security, select the Valid CLS box. By default the Valid RLS checkbox is selected but no condition is specified in the Record Level Security tab. In this case, all the users, groups, and roles do not have any permissions.
- Leave the Disable Policy Settings option unselected.
- In the Record Level Security tab, specify the security conditions for the user/role/group. If no condition is added, the user/role/group will not be able to view any records, unless it inherits permissions from its other roles and groups.
- Select next to the Expression text box to specify the field on which to build the condition in the Expressions dialog. You can also type the name of the field manually in the text box (the format should be @FieldName or @"Field Name" when the field name contains blank space).
- From the Operator drop-down list, set the operator with which to compose the condition.
- Select next to the Value text box to specify the value of how to compose the condition using the Expressions dialog. You can select the special field User Name or a parameter in the Expressions dialog as the value to compose the condition dynamically (the usage of parameter in a security condition is similar to that of in a query filter condition).
You can also specify the value manually if you are familiar with the values of the specified field. When you type in the value: String values should be quoted with single quotes; the format of Date values should be consistent with that of your database; multiple values should be separated with ","; if "," or "\" is contained in the values, write it as "\," or "\\".
- If you want to append a new condition line, select and select AND or OR from the drop-down menu. To add a new group, select beside the condition line which shows End or End Group, then select New Group and specify the relationship between two adjacent groups.
The following table lists the options that are available for adding condition lines and groups:
Option Description AND Specifies the relationship between two expression statements as logical AND. If this line is the last line in the expression list, when you select AND or OR, a new line will be appended to the end of the list. OR Specifies the relationship between two expression statements as logical OR. If this line is the last line in the expression list, when you select AND or OR, a new line will be append to the end of the list. Insert Row Inserts a new line behind the current line. Delete Row Deletes the current line. New Group Adds a new expression group to the list. The relationships between two groups can be:
- AND - Logical AND relationship between two groups. Records satisfying both condition groups will be retrieved.
- OR - Logical OR relationship between two groups. Records satisfying either one of the condition groups will be retrieved.
- AND NOT - Records satisfying the first and not the second condition group will be retrieved.
- OR NOT - Records satisfying the first or not the second condition group will be retrieved.
- In the Column Level Security tab, make a choice:
- Select the Select Column option and then select the DBFields, formulas, parameters, or summaries. You can set the selected columns to be shown or hidden from the user/role/group by selecting the Allow or Deny option. Whether the principal can see the unselected columns depends on whether the parent groups/roles allow them.
- Choose Allow all to show all the columns to the user/role/group.
- Choose Deny all to hide all the columns from the user/role/group.
- Repeat steps 6 to 10 to customize another principal's record level security and column level security settings.
- Select OK to create the security policy.
Once a security entry is created, you can further edit it, rename it, or delete it according to your requirement. To do this, right-click the security entry in the Catalog Manager resource tree and select the corresponding option on the shortcut menu.
You can import or export your security information from/to external XML files (*.acl.xml) when editing security in Logi Report Designer. While if you want to use XML security information, you must first purchase a special license. For more information, contact Logi Analytics Support (firstname.lastname@example.org).
- To import the security information from an XML file, select in the User/Group/Role panel and then select Import from File from the drop-down menu. In the Open an xml file dialog, select the XML file that contains the required security information and then select Open.
- To export the security information to an XML file, select in the User/Group/Role panel. In the Save dialog, specify the name of the file and the location where to save it, then select Save.
The security information contained in the XML file is shown as follows:
You can create your own XML format security information files according to the above structure. However, the best way to generate an XML security information file is to use the Security dialog. With this dialog, you can edit the security information, and then export it to an external XML file.
For example, if the simple security policy has been set up as follows:
|Belongs to Role:||d_d_r1|
|Permissions:||(@"Customer ID">=5 AND @"Customer ID"<=10) AND @"YTD Sales"<=65000|
|Belongs to User:||d_d_u1|
The corresponding XML code would be:
<ACL version="1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
You can apply a security entry to a page report or library component by setting the Security Policy Name property on its datasets. However, since Column Level Security (CLS) is not supported on library components at present, you will only get the security entries which do not contain CLS in the value list of library components' Security Policy Name property.
- Select File > Open to open the page report or library component to which you want to apply the security policy.
- In the Report Inspector, select the name of a dataset used in the page report or library component under the Datasets node for page report or Data Source node for library component.
- In the Security section of the Properties sheet, select a required security entry for the Security Policy Name property.
- You can repeat the above steps to apply security entries to other datasets in the page report or library component.
After the page report or library component is published to Logi Report Server, when different users log onto the server and run it, they will only see the data they are supposed to see. However, as the user defined users, groups, and roles in a security entry may not be recognized by Logi Report Server, if your security policy contains such users, gropus, or roles, you need to first create them respectively on Logi Report Server, and then in Logi Report Designer, synchronize the security information with the server by means of importing security information from the server with the Merge option selected.
However for page reports, the security entries for the primary reports and subreports can be set and applied individually, with different combinations causing different results. The relationships between the security policy settings and the viewing results are shown in the following table:
|Primary Report||Subreport||Users in Policy||Users NOT in Policy|
|Ð||Ð||No security policy is applied to either the primary report or the subreport. Users can therefore view all records in both reports.|
|Ï||Ð||Can view specified records in the primary report and all records in the subreport.||Can view no records in the primary report and all records in the subreport.|
|Ð||Ï||Can view all records in the primary report and specified records in the subreport.||Can view all records in the primary report and no records in the subreport.|
|Ï||Ï||Can view specified records in both the primary report and the subreport.||Can view no records in either the primary report or the subreport.|
Ï - Security policy has been set and applied.
Ð - Security policy has not been set and applied
Record Level Security (RLS) can also be of report scope, that is, you can create different record level security policies for different reports. When a report is applied RLS of both the report and data source scopes, the report scope RLS will override that of the data source scope. Column Level Security (CLS) is not supported at report scope.
You cannot apply RLS at report scope to reports created using business views, that is it is only supported on page reports that are based on queries.
To set up a record level security policy for a query based page report:
- Select File > Open to open the page report.
- In the Report Inspector, select the name of a dataset used in the page report under the Datasets node.
- In the Security section of the Properties sheet, select in the value cell of the Record Security property, then select .
The Record Level Security Information dialog appears.
- Select the Add button to add a condition line and edit the security information by selecting corresponding cells.
If you want to use more values in one cell, use "|" to separate them (applies to the User, E-mail, and Title cells). This is useful when you want to apply the same conditions to multiple users. For example, if you want user1, user2, and user3 to share the same security setting, type user1|user2|user3 in the User cell, and then define the security condition.
- Add more condition lines as required. If you want to apply more than one condition expression to a user, you can edit the condition expressions in several individual lines, typing in the same user name for each line. For such compound conditions, the relationship among them is logical OR.
You can also create a text file, add the security settings, and then select Import Text to import the security information from the text file into the Record Level Security Information dialog. After importing, you can select the cells to further edit the security settings. Note that when you create the text file to include the security information, you should use TAB to separate each item, and always keep the headings (User, Role, Column, and so on) on the first line of the text file. For example,
User Role Column Operator Value Title admin admin user1 Customer ID >= 10 email@example.com Mr. user1 Customer Name = 'Absolute Java' user2 Customer Name IN ('Absolute Java','American Coffee Inc.') firstname.lastname@example.org Miss user3 Phone IN ('(212) 555-3462','(317) 555-1274') email@example.com Mrs.
- Select OK to finish defining the security information and close the dialog.
- You can also use a formula to specify the security condition and set it as value of the Function property on the dataset of the report to control the RLS conditions on the report.
For example, if user1 should only see records which satisfy the condition State = 'CO' and Customer ID >= 10, you can create a formula as follows:
if ( @State == 'CO' && @"Customer ID">= 10 ) return "user1"
Then from the value list of the Function property, select the formula.
When the Record Security and Function properties have been set to control the record level security on a report, both will take effect, and the relationship between them is logical OR.
- You can repeat the above steps to define record level security on the rest datasets in the page report.
After the report is published to Logi Report Server, when different users log onto the server and run it, they will only see the data they are supposed to see.
Note: In the Record Level Security Information dialog, the date values provided in the drop-down list may not be valid for your database, because they are date values that have already been reformatted using your date format settings in Logi Report. For detailed information on how to set the date format in Logi Report Designer, go here.