Topics Map > Technology > Denodo

Denodo - Access and Permissions Within a Denodo VDB

This document will describe how a unit’s Denodo Admin will maintain and adjust their employees’ access to their unit’s Virtual Database (VDB).

This process will only allow them access to the different views created within their unit’s VDB, but access to the data itself is dependent on the user’s access to that source data. For example, the Logical Data Warehouse (LDW) in Denodo is an exact virtual replication of the Enterprise Data Warehouse (EDW). A user’s access to the different tables/views in the LDW is determined by their access to the data in the EDW. Similarly, access settings in your unit’s proprietary data sets that are connected to Denodo will determine access within Denodo.

At VDB Creation

At the time your unit requests a VDB, you will need to supply the full distinguished name (DN) for two (2) separate active directory (AD) groups.

  • Admin AD group: membership of the Admin AD group should only include administrators of the VDB - those creating data sources, maintaining access, etc.
  • Additional AD groups: membership in additional AD groups should include developers (those creating derived views from data sources/base views created by the Admin AD group.

NOTE: each DN cannot exceed 99 characters.

Use the following form to request your AD groups be applied to your VDB:

Denodo Services Form

Role Management

To add or remove a user’s access to view and/or edit contents in the VDB, simply add or remove users from the two AD groups using the method you prefer.

Privileges

You can grant/revoke all the access rights (ALL PRIVILEGES) or a list of the following ones, to a user/role, over a database.

Connect

Users with the Connection privilege can connect to this database.

  • To revoke all the privileges of a user temporarily, revoke the roles and the connection privileges over all the databases.

Create

Users with the Create privilege can create and drop data sources, views, stored procedures, Web services, etc.

  • Execute CREATE statements.
  • If the user wants to create a derived view, they also need to have “METADATA” privilege over the entire database or at least, over the views involved in the new view.
  • To allow users to create temporary tables but not other types of elements, grant the role create_temporary_table to these users.
  • When a user creates an element, by default, METADATA and WRITE privileges are automatically assigned. It only happens for users that exist in Virtual DataPort (not for Kerberos/LDAP/SAML/OAUTH/DnDToken authenticated users).

Create Data Source

Users with the Create Data Source privilege can create and drop data sources.

  • Execute CREATE DATASOURCE statements.

Create View

Users with the Create View privilege can create/drop views, stored procedures, and types.

  • Execute CREATE WRAPPER, CREATE TYPE, CREATE WRAPPER and CREATE PROCEDURE statements. This includes materialized and temporary tables. 
  • In addition, they need the privilege “METADATA” over the views referenced by the new view, or their database.
  • To allow users to create temporary tables but not other types of elements, grant these users the role create_temporary_table. 

Create Data Service

Users with the Create Data Service privilege over a database can create web services (REST and SOAP), widgets, and JMS listeners.

  • Execute CREATE REST/SOAP WEBSERVICE, CREATE WIDGET and CREATE LISTENER JMS.

Create Folder

Users with the Create Folder privilege can create folders.

  • Execute CREATE FOLDER  statements.

Metadata

Users with the Metadata privilege can do the following:

  • View the list of views and stored procedures of the database.
  • Execute LIST statements.
  • View the schema of the views and stored procedures. 
  • Open the dialogs Edit and Options of the views. However, without the write privilege, the user will not be able to modify the view.
  • Open the Tree view and Data lineage of the views.
  • Obtain the execution plan of any query, without actually running the query.
    • To see the query plan of a query, open the Execute dialog of the view and click Query plan. Alternatively, open the VQL Shell and prefix the query with DESC QUERYPLAN.

Execute

Users with the Execute privilege over a database can do the following:

  • Perform introspection of data sources.
  • Query any view/stored procedure of the database. 
  • Execute SELECT/CALL statements.

If you grant this privilege to a user or role, over aspecific view or stored procedure instead of a database, the user will be able to query the view/procedure. 

  • Execute SELECT/CALL statements.

You can grant more fine-grained EXECUTE privileges over specific views:

  • Column privileges
  • Row restrictions

Write

Users with the Write privilege over a database can do the following:

  • Modify and delete the data sources, views, web services (REST and SOAP), stored procedures and widgets of the database.
  • Move elements across the existing folders of the database, except if that element is another folder.
  • Deploy, redeploy, and undeploy web services.
  • Deploy, redeploy, and undeploy the auxiliary web services of widgets.

Insert

Users with the Insert privilege can execute INSERT statements over the view. The column restrictions may affect to INSERT operations.

Update

Users with the Update privilege can execute UPDATE statements over the view.

Delete

Users with the Delete privilege can execute DELETE statements over the view.

Column-Level Security

Column privileges limit the columns a user/role can use in a query.

To implement Column-Level Security, perform the following steps:

  1. Navigate to the Administration tab and select Role Management.
  2. Check the box for the role this restriction will apply and select Edit privileges.
  3. Click the pencil icon in the Advanced column of the appropriate VDB.
  4. Click the pencil icon in the Column privileges column of the view on which the restriction will apply.
  5. By default, all columns are selected. Deselect the columns that you do not want the user to execute and select Ok.
  6. Select Save.

Row-Level Security

Row privileges allow different actions over subsets of rows:

  • Reject rows
  • Reject rows if some sensitive fields are used
  • Mask sensitive fields

To implement Row-Level Security, perform the following steps:

  1. Navigate to the Administration tab and select Role Management.
  2. Check the box for the role this restriction will apply and select Edit privileges.
  3. Click the pencil icon in the Advanced column of the appropriate VDB.
  4. Click the pencil icon in the View Restrictions column of the view on which the restriction will apply.
  5. Click New.
  6. Enter the restriction condition and action and select Ok.
  7. Press Ok at the Assign Restrictions screen.
  8. Select Save.

Keywords:
Enterprise Logical Data Warehouse EDW LDW distinguished name DN 
Doc ID:
136729
Owned by:
Learning Systems Support in UI Training and Development Resources
Created:
2024-04-10
Updated:
2025-01-23
Sites:
University of Illinois Training and Development Resources