Securing Data
It's equally important to be able to control access to data and Logi Info provides several ways to accomplish that.
Securing Connections and Metadata
The Metadata element provides a method of controlling the data objects available to users who use the Active Query Builder (with the Analysis Grid or InfoGo application) through the use of metadata files. The Metadata element includes a Security Right ID attribute that can be used to prevent unauthorized users from working with that data. A browser-based tool, the Web Metadata Builder, that can be used to create data connections and metadata files is available inside InfoGo and other Logi applications. Access to this tool is controlled by Security Right IDs entered into the Security element's Metadata Admin Security Right IDs attribute.
Security Tokens and SQL Queries
The user-related security information collected when the user is authenticated is available in definitions through the use of tokens, including @Function.UserName~, @Function.UserID~, @Function.UserRoles~, and @Function.UserRights~. The last two tokens provide their values, if there's more than one, as a comma-separated list.
The availability of these tokens allows developers to use SQL queries and datalayer security filters to restrict data based on the user's Rights. Assume that the current user has been assigned two Roles, "Accounting" and "Retail Division" (based on the organizational departments he belongs to) and needs to view a report that summarizes expenses by department. The report should only present data to him for the departments he belongs to. This can be accomplished with this SQL query:
SELECT * FROM ExpenseData WHERE Department IN (@SingleQuote.Function.UserRoles~)
The @Function.UserRoles~ token contains a comma-separated list of the user's two Roles. The inclusion of the SingleQuote token prefix causes each of the individual Roles in the list to be surrounded with single quotes, which is the format required for the SQL query's "IN" clause. The result set will only include rows with data for the user's two departments.
Security Tokens and Filters
The same kind of comparisons can be used to filter data after it's been retrieved into a datalayer. In this example, assume users have been assigned a Role that indicates their office region, such as "Northeast" or "Midwest", and they are only allowed to see report data for their region.
As shown above, the report definition can contain a Compare Filter beneath its datalayer. It will filter out any rows in the datalayer whose Region column value doesn't match any of the regions specified in the user's Rights list.
The Security Filter Element
Logi Info also includes the ability to impose row-levelsecurity using the Security Filter element, which filters data after it has been retrieved into a datalayer. To restrict access to specific data rows, one or more Security Filter elements are added as child elements of a datalayer.
In the example above, a Security Filter element has been added to a report definition that displays employee data. The purpose of this filter element is to allow basic users to see all data rows retrieved into the datalayer except those of Executive-class employees. Datalayer rows that do not cause the formula in the filter's Condition attribute to evaluate to True will be removed. Its Security Filter Right ID is set to the Right associated with the role of the basic user.
When the report is generated, this filter element will only be applied if the current user has the Role of a basic user.
Next, a second Security Filter element has been added, as shown above. The purpose of this filter element is to allow privileged users to see all data rows retrieved into the datalayer. Its Condition attribute value, which is required, is set to an expression, 1=1, that will always evaluate to True. Its Security Filter Right ID is set to the Right associated with the Role of privileged users. When the report is generated, this filter element will only be applied if the current user has the Role of those allow to view Executive Reports, i.e. the privileged user.
Keep in mind that the Security Filter element behaves very differently than a Compare Filter element. Whereas the Compare Filter will remove datalayer rows that fail to meet certain criteria but allow all others to be available, the Security Filter prevents the datalayer from providing any rows, unless the current user's Rights match at least one of the Security Filter's Rights. This prevents a user who has not been granted any Rights from seeing all datalayer rows.
The Include Condition Attribute
The Security Filter element also has an Include Condition attribute. If the value of this attribute is left blank or contains a formula that evaluates to True, the Security Filter is applied to the datalayer. If the value evaluates to False, the filter is ignored and does not affect the datalayer. This powerful feature allows you to dynamically determine if security will be applied to the datalayer or not, or to switch between different Security Filters at runtime.
Column-Level Security in Data Tables
Logi Info can also restrict data displayed in Data Tables at the column level by adding or removing table columns based on security Rights.
As shown above, a Data Table Column element can have its Security Right ID attribute value set so that the column will only appear in the table for users granted the required Right.
As discussed here, Logi Security provides opportunities to control the retrieval and presentation of data in Logi applications in a variety of ways. Developers are encouraged to experiment to find the approach best suited to their requirements.