Managing access to virtual objects in Data Virtualization

Data Virtualization Admins and Engineers can grant users or groups access to virtual objects in Data Virtualization.

To grant groups access to virtual objects in Data Virtualization, you must create the groups in Cloud Pak for Data first. For more information, see Managing user groups.

Follow these guidelines when you name users and groups:
  • Group names must be less than or equal to the group name length listed in SQL and XML limits.
  • Group names are treated as case-insensitive in the Data Virtualization Db2 catalogs. Avoid using identically named groups with different character case, such as MyGroup and MYGROUP.
  • A username on Windows can contain up to 30 characters.
  • When not using Client authentication, non-Windows 32-bit clients that connect to Windows with a username that is longer than the username length listed in SQL and XML limits are supported when the username and password are specified explicitly.
  • A username must not be USERS, ADMINS, GUESTS, PUBLIC, LOCAL, or any SQL reserved word.
  • A username must not begin with IBM®, SQL, or SYS.
Important: When you revoke user access from Data Virtualization or Cloud Pak for Data, object-level authorizations remain for the username in Data Virtualization. If a user with that username is later granted access to Data Virtualization, the user inherits the object-level authorizations that previously were granted to that username. As a best practice, do not reuse usernames for different users in your organization.
Note: Data Virtualization authorizations are assigned to role and group names. If a group is renamed, a Data Virtualization Admin must migrate the group-level authorizations. In the Admin role, you can migrate the authorizations by running the MIGRATE_GROUP_AUTHZ stored procedure.
For example, you can run the following procedure in the SQL Editor in Data Virtualization:
CALL DVSYS.MIGRATE_GROUP_AUTHZ('OLD_GROUP_NAME', 'NEW_GROUP_NAME');
This procedure migrates the following authorizations:
  • Database-level authorizations (DBAUTH)
  • Roles that are assigned to groups (ROLEAUTH)
  • Schema-level authorizations (SCHEMAAUTH)
  • Table-, view-, and nickname-level authorizations (TABAUTH)
  • Routines (ROUTINEAUTH)
  • Data source-level authorizations
After you migrate the authorizations, revoke the Data Virtualization service role from the old group name and assign it to the new group.
For more information about the stored procedure, see MIGRATE_GROUP_AUTHZ stored procedure in Data Virtualization.

You must assign roles to existing Cloud Pak for Data users or groups. For more information, see Managing roles for users and groups in Data Virtualization.

Learn more