Managing access to virtual objects in Watson Query

Watson Query Admins and Engineers can grant users or groups access to virtual objects in Watson Query.

To grant groups access to virtual objects in Watson Query, 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 Watson Query 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 Watson Query or Cloud Pak for Data, object-level authorizations remain for the username in Watson Query. If a user with that username is later granted access to Watson Query, 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: Watson Query authorizations are assigned to role and group names. If a group is renamed, a Watson Query 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 Watson Query:
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 Watson Query 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 Watson Query.

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

Restriction:

Watson Query access control is not enforced on the preview in other Watson services when data masking or row-level filtering is applied. For access control in the other Watson services, you must define your rules to manage access to the catalogs, projects, data assets, or connections.

The preview is subject to the data protection rules and catalog or project access control only.

Even though a user does not have access to query an object from Watson Query, they might be able to preview the object in a catalog or project if they have access to the catalog or project where the data asset resides.

Learn more