Docs
...
Authorization model for views

Authorization model for views

Last updated: Mar 17, 2025
Authorization model for views with the Data Virtualization authorization model

Data Virtualization uses the authorization model for views, and the masking and row filtering model for views to enhance security by restricting access to data, and by limiting visible data based on user roles.

To determine whether you can access the view, Data Virtualization initiates the following Db2 authorization checks:

  1. Are you authorized to access the view through IBM Knowledge Catalog and Data Virtualization GRANTs?
  2. Is the creator of the view continuously authorized, through IBM Knowledge Catalog and Data Virtualization GRANTs, to access the objects and views that the view references?

In the following example, a user (userA) is authorized to access the view but not the contents in the tables that the view references. The creator of the view (viewCreator) remains authorized to the objects that the view references for the view to remain accessible to userA.Diagram illustrating how a user must have authority to access a view, and that the view will only remain accessible if the view creator has authority to access the tables the view references to.

For more information on the authorization convention established by Db2, see Views.

For more information on managing user access, see Managing access to virtual objects in Data Virtualization.

Column masking and row filtering model for views

Following the Db2 convention, Data Virtualization applies column masking and row filters directly to objects that a view references.

Data Virtualization does not apply masking and row filtering rules to a view in a governed catalog. In Data Virtualization, views are masked according to the data protection rules that apply to the objects that the view references. These rules are always evaluated against the user that is accessing the view. This model allows you to protect sensitive data in columns and rows in your virtual tables, ensuring that all derived views that reference that data follow those rules.

The following diagram illustrates this process: When a user (userA) attempts to access the Department expenses view, Data Virtualization applies column masks and row filters to the underlying Payroll and Transactions tables. The resulting view is masked regardless of any column masking or filter rules that are applied directly to the Department expenses view. This process ensures that userA cannot bypass data protection rules applicable to the underlying data referenced by the Department expenses view.Diagram illustrating how a user (userA) is returned a masked view, which is masked according to the masking and row filtering rules applicable to the tables that the view references.

When the rules evaluation results in Deny on tables that a view references, the view is not masked. The Deny action occurs when evaluating a user on a referenced table results in the Allow or Deny rule and not a column mask or row filter rule. If you want to mask the views and deny access to the tables referenced by the views, then apply masks through IBM Knowledge Catalog data protection rules and deny access through Data Virtualization authorizations.

For more information, see Masking virtual data in Data Virtualization.

Outcome truth tables

The following outcome truth tables indicate the net outcome for a view creator (viewCreator) and another user (userA) when they query a view (V1) that references tables (T1).

  • The decisions in each table represent net outcomes from the applicable IBM Knowledge Catalog data protection rules.
  • Consider this legend for the following outcome truth tables:
    • Any decision
      Allow, Deny, Transform, or Transform → Deny
    • Transform
      Column masking, row filtering, or both rules, apply.
    • Transform → Deny
      The case when the Deny decision overtakes a transformation (masking and row filtering) rule.

For more information on rules setting, see Managing rule settings (IBM Knowledge Catalog).

Table 1. Net outcome for viewCreator on V1 based on viewCreator decisions made on T1 and V1
viewCreator decision on T1 userA decision on T1 viewCreator decision on V1 userA decision on V1 Net outcome for viewCreator on V1 from Data Virtualization
Allow1 – Allow – Allow
Allow1 – Transform – Allow
Any decision1 – Transform → Deny – Deny
Any decision1 – Deny – Deny
Transform1 – Allow – Transform decision for viewCreator on T1
Transform1 – Transform – Transform decision for viewCreator on T1
Transform → Deny1 – Any decision – Deny
Deny1 – Any decision – Deny

1Evaluation decision that is used in RCAC and authorization enforcement.

Table 2. Net outcome for userA on V1 based on decisions made by viewCreator on T1, and userA decisions made on T1 and V1
viewCreator decision on T1 userA decision on T1 viewCreator decision on V1 userA decision on V1 Net outcome for userA on V1 from Data Virtualization
Allow or Transform Allow2 – Allow Allow
Allow or Transform Allow2 – Transform Allow
Any decision Any decision2 – Transform → Deny Deny
Any decision Any decision2 – Deny Deny
Allow or Transform Transform2 – Allow Transform decision for userA on T1
Allow or Transform Transform2 – Transform Transform decision for userA on T1
Allow or Transform3 Transform → Deny2 – Allow3 Allow3
Allow or Transform3 Transform → Deny2 – Transform3 Allow3
Allow or Transform3 Deny2 – Allow3 Allow3
Transform → Deny or Deny Any decision2 – Any decision Deny

2Evaluation decision that is used in RCAC enforcement.

3As long as viewCreator is not denied access to the tables that the view references, and userA is not denied access to the view itself, then userA has unrestricted access to the data unless a Transform rule applies to userA on the tables that the view references.