A complete data security rule policy uses the same data models and data security rules to provide data to all users. The data is accessed from gadgets in dashboards or from report designs created using either BIRT Designer Professional or Report Studio.

Corporate security policies drive all other data security rule considerations. The developer of any set of data security rules must ensure that corporate security policies are implemented in those security rules.

The data object developer controls the granularity of data sets, categories, and data security rules. The granularity of user groups in the iHub volume is imposed on the data object developer.

Increasing the granularity of categories and data security rules refines a data rule security policy but increases the complexity of the implementation. To reduce this complexity, consider using multiple data models each containing categories using a subset of the data sets available in the data object. Name each model so that its contents and purpose are readily understood by Report Studio users.

Increase the granularity of categories and data sets to ensure that the data model provides the expected number of records to a user. For example, a single data set that returns a row containing customer, order, order detail, and product fields returns multiple records for each product. Adding a data security rule based on the customer’s country filters the set of products visible to the user, but still returns multiple records for each product. Creating separate categories for each underlying table does not reduce the number of duplicates because the query for the data set returns the same number of records. Instead, use separate data sets for each data source table required in the data model. This structure returns the expected number of product rows without duplicates.

A data model enforces data security rules by creating implicit joins, if necessary, using the defined links between data sets. Assigning a data security rule that uses a field from one category to another category causes the use of implicit joins. If the data model contains many data sets, the number of implicit joins can increase the time taken to access the data records.

Create multiple data models to reduce the number of joins between data sets used together. For example, if a rule using a customer’s country is assigned to another data set and the number of links between the data sets is more than five, consider creating another data model that links the two data sets more directly. Name each model so that its contents and purpose are readily understood by Report Studio users. To test the response time for each set of users, create report designs that use data sources returning a realistic number of records.

Each data security rule assigned to a category or column rejects a record from the result set if the rule evaluates to false. Take care in designing the set of security rules in a data model to ensure that rules neither exclude required records nor include extra records. If multiple rules are assigned to a category, the effect is equivalent to joining the requirements by a logical AND. Using multiple security‑ID conditions in a single call to the hasUserACL( ) function is equivalent to joining the requirements by a logical OR. For example, the following rule assignments are not equivalent:

and:

The first two rules require the user to have both the Manager security ID and the security ID of the country to see a data row. A user who needs to see data for all countries must be a manager and have explicit access to every country. If the data source gains data rows for a new country, the iHub system administrator must add the security ID to the users who need to see the new data.

The second, single rule requires the user to have either the Manager security ID or the security ID of the country to see a data row. Any manager sees all the data rows. A user who has only the country security ID sees only the rows for that country.