Rules of Visibility and Data persistency entitlements

The Rules of Visibility and Data persistency entitlements modules are used to assign what the user is entitled to view, add, and update.

These entitlements depend on the data values on a transactional basis, rather than which transactions the user can execute. The rules are defined in the System Maintenance Security option.

The two types of data level entitlements discussed in this manual, Data persistency entitlements and Rules of Visibility, are closely linked. The Rules of Visibility (RoV) module allows administrators to define what elements and sub-elements users and user groups can see based on defined constraints. At runtime, the rules are evaluated at post-transaction, and transaction data sets are filtered based on the defined rules. For more information about defining RoV, see the developer documentation.

The Data persistency entitlements module allows administrators to define the elements and sub-elements that users and user groups can add and update, based on defined constraints. At run time, the rules are evaluated pre-transaction to determine if the user has been entitled to add or update the data within the transaction set based on the defined rules.

You can control who sees what and who can add persistent data to a record using data level entitlements, set though the Rules of Visibility and access tokens. Data level entitlements are rules that dictate whether or not a user can view or persist certain sets of data. InfoSphere® MDM defines two categories of Data persistency entitlements:
  • Rules of Visibility entitlements, which control the data that a user is allowed to view based on the defined rules and constraints.
  • Data persistency entitlements, which control the data that a user is allowed to add or update based on the defined rules and constraints.
The use of these two types of entitlements is sometimes referred to as row and column level security because both the instance of data and the type of data is considered. An example of controlled instance of data would be where one category manager is not allowed to view a specific categories because those categories are managed by a different category manager. An example of controlled type of data would be where a given user is not given permission to view category relationships and category codes for all categories.InfoSphere MDM processes entitlements at two levels. The first is at the database level, which is referred to as Accessibility. For Rules of Visibility, this provides database-level filtering of data based on access tokens. The second level is in the data-level entitlements engine. For Rules of Visibility this provides post-inquiry filtering of data based on more complex rules and constraints; for Data persistency entitlements this ensures that the user is entitled to make adds or updates to that entity, prior to invoking calls on the database. These two levels, or mechanisms, should be considered together when deriving a strategy around data level entitlements. For example, the Accessibility mechanism can provide a coarse-grained filtering of data that a user has access to in a high performing manner, followed by additional filtering by the Rules of Visibility engine, which applies a more complex logic that is not suited or possible to contain in database queries.