Authorization model for views

Data Virtualization uses the Db2 authorization model for views, which controls access to database objects (authorizations), along with masking and row filtering rules to enhance security by limiting access to data based on the defined conditions.

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?
Authorization user scenario

The following diagram illustrates the scenario of a user (userA) that is authorized to access the Department expenses view but not the contents in the tables that the view references. The creator of the view (viewCreator), creates the Department expenses view from the Payroll and Transactions table, and must remain authorized to these 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.

Column masking and row filtering model for views

Data Virtualization applies these rules to users accessing a view:
  • Data Virtualization applies column masking and row filters directly to objects that a view references, instead of applying them to a view in a governed catalog.
  • Data Virtualization masks views according to the data protection rules that apply to the tables that the view dependency chain references.
This model allows you to protect sensitive data in columns and rows in your base virtual tables, helping ensure that all derived views that reference that data follows those rules.

Masking and row filtering user scenario

The following diagram illustrates the scenario of 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 helps ensure 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.

Outcome truth tables

When the rules evaluation results in Allow or Deny on tables that a view references, the view is not masked. This outcome 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.
Note: 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. See Masking virtual data in Data Virtualization.

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 take precedence over a transformation (masking and row filtering) rule to the Default data convention and Rule action precedence is enacted. For more information, see Managing rule settings.
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-only rule applies to userA on the tables that the view references.

Learn more