Virtual table SAF security

A single Data Virtualization Manager server environment can provide data virtualization to multiple independent tenants or application groups. The virtual table SAF (system authorization facility) security feature provides a SAF mechanism to secure virtual tables so that each tenant can only access tables authorized for members of the tenant group.

Activating this security feature will prevent using virtual table names in metadata queries (such as, SQLENG.TABLES, SQLENG.COLUMNS), as well as querying or updating application data mapped using unauthorized table names.

Server interface parameter

The SQLVTRESOURCETYPE parameter in the PRODSECURITY parameter group defines a security class name for virtual table resource checking. By default, this system parameter defaults to the value 'NON' indicating that security checking is disabled.

When activated with a class name, the SQLVTRESOURCETYPE parameter will enable SAF resource checking on metadata queries (such as, SQLENG.TABLES, SQLENG.COLUMNS) as well as virtual table queries using the resource name resource_class.table_owner.table_name where:
  • resource_class is the class name defined for the RESOURCETYPE parameter in the PRODSECURITY parameter group (for example, RAVZ)
  • table_owner is the SQL table owner name. By default, this parameter is set to the schema name of the virtual table or to DVSQL (if the virtual table is not assigned to a schema). This parameter is scheduled for deprecation.
  • table_name is the map (or virtual table) name as defined in the map data set

For improved performance in SAF calls, RACROUTE REQUEST=FASTAUTH provides general resource checking. A separate INTRNLONLY parameter named ‘DISABLE FASTAUTH SECURITY CHECKS’ disables the use of FASTAUTH if security problems are encountered. Disabling FASTAUTH will switch to RACROUTE REQUEST=AUTH checking on all resource rules that can degrade query performance on metadata tables.

When securing metadata tables, READ access is required to query rows in the following tables.

Tables Populated state
SQLENG.COLUMNS Y
SQLENG.COLUMNPRIVS N
SQLENG.FOREIGNKEYS N
SQLENG.PRIMARYKEYS Y

Dependent on tables with keys such as VSAM KSDS, IMS, specific DRDA sources, ADABAS, etc.

SQLENG.ROUTINES N
SQLENG.SCHEMAS Y

There are two defaults: SQLENG and DVSQL for non-schemas.

SQLENG.SPECIALCOLS Y

ALT Index for specific columns, DRDA with multiple index, ADABAS super descriptor

SQLENG.STATISTICS Y

Dependent on RUNSTAT

SQLENG.TABLES Y

T for virtual tables and V for virtual views

SQLENG.TABLEPRIVS N

Securing tables using the generic profile SQLENG.* is also an option if preferred.

Securing specific virtual tables is also required when activating this feature. Securing virtual tables by specific or generic rules activates two security checks:
  1. When querying metadata tables (SQLENG.*), users must minimally have READ access to the virtual tables for rows related to a table to be returned. In this case, no errors are returned. Instead, the information about a specific table is omitted from the result set, and the user does not indicate that the table exists.
  2. When querying virtual tables, the user must have READ access to each table in the SQL SELECT statement and UPDATE access to any table that is the target of an SQL INSERT, UPDATE, or DELETE statement.

Restrictions and Considerations

Virtual table authorization checking is built on general resource checking and is impacted by the following product parameter in the PRODSECURITY group:
  • ALLOWUNPROT – The ALLOWUNPROT parameter allows access to unprotected resources. When set to YES, this parameter allows access to resource names that have no matching resource definition in the SAF database. ALLOWUNPROT should be set to NO to ensure that resource rules are processed correctly.

All SQL queries are automatically secured when this feature is activated unless ALLOWUNPROT is set to YES. This means that resource rules must exist to allow READ access to the metadata tables SQLENG.*.

This feature is limited to SQL access to virtual tables. Users authorized to create tables can create tables that may not be accessible due to SQL access rules implemented using this feature.

RACF profile name

For RACF authorization, DVM is now updated to support a resource profile name up to 128 bytes in length.

To increase the allowed length of a RACF resource profile name in z/OS:

  • Modify the MAXLEN attribute within the DVM CLASS definition in the RACF database.
  • Update the Class Descriptor Table (CDT) entry for the DVM class to reflect the new maximum length of 128 bytes.
  • Run the following command to build or refresh the dynamic CDT before restarting the system: SETROPTS RACLIST(CDT).
Note: The RACF profile name change is performed only if an existing CLASS is being used.