User and Access Right in Virtual DataPort

Denodo Virtual DataPort distinguishes two types of users:

  • Administrators. They can create, modify and delete databases without any limitation. Likewise, they can also create, modify and delete users. When the server is installed, a default administrator user is created with user name admin and password admin. There must always be at least one administrator user.

  • Normal users. They cannot create, modify or delete users or databases. Administrator users can grant them connection, Execute, create or write privileges to one or several databases or to specific views contained in them.

    An administrator can promote a normal user to administrator of a database of one or more databases, which means that this user will be able to perform administration tasks over these databases.

    A normal user with the role serveradmin can perform the same actions as an administrator.

A “Normal user” can have “Roles”, which are a set of access rights over databases and their views and stored procedures. Roles allow administrators to manage user privileges easily because by changing the privileges assigned to a role, they change the privileges of all the users that “belong” to that role.

Types of Access Rights

Virtual DataPort access rights are applied to a specific user or a role, to delimit the tasks they can perform over databases, views and stored procedures.

The following access rights only affect “Normal” users. That is because normal users promoted to local administrators of a given database can perform any task within that database and administrators can perform any task within the entire Server.

An administrator with the role “assignprivileges” can grant privileges to a user or a role, over an entire database or over specific views or stored procedures of a database.

You can grant the following privileges to a user or a role, over a database:

Connection Privilege

Users with the Connection privilege can connect to this database.

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

Create Privilege

Users with the Create privilege can do the following:

  • Create/drop data sources, views, stored procedures, Web services, etc. I.e. execute CREATE statements. If the user wants to create a derived view, she also needs to have Execute access over the entire database or at least, over the views involved in the new view.
  • Deploy and redeploy the Denodo Web services that they created.
  • Deploy and redeploy the auxiliary Web services of the widgets that they created.

Create Data Source Privilege

Users with the Create Data Source privilege can do the following:

  • Create/drop data sources i.e. execute CREATE DATASOURCE statements.

Create View Privilege

Users with the Create View privilege can do the following:

  • Create/drop views, stored procedures and types i.e. execute CREATE WRAPPER, CREATE TYPE, CREATE WRAPPER and CREATE PROCEDURE statements. If the user wants to create a derived view, she also needs to have Execute access over the entire database or at least, over the views involved in the new view.

Create Data Service Privilege

Users with the Create Data Service privilege can do the following:

  • Create/drop web services, widgets and JMS listeners i.e. execute CREATE REST/SOAP WEBSERVICE, CREATE WIDGET and CREATE LISTENER JMS statements.
  • Deploy and redeploy the Denodo Web services that they created.
  • Deploy and redeploy the auxiliary Web services of the widgets that they created.

Create Folder Privilege

Users with the Create Folder privilege can do the following:

  • Create/drop folders i.e. execute CREATE FOLDER statements.

Execute Privilege

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. I.e. execute SELECT/CALL statements.

If you grant this privilege over a specific views or stored procedure instead of a database, the user will be able to do the following:

  • Query the view/procedure. I.e. execute SELECT/CALL statements.

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

Metadata Privilege

Users with the Metadata privilege can do the following:

  • View the list of views and stored procedures of the database. I.e. 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. For example,

    DESC QUERYPLAN
      SELECT count(*), sum(total)
      FROM invoice
      GROUP BY billing_state
    

If you grant the privilege metadata over a set of views/procedures instead of a database, the differences are:

  • The user will only have access to these views/procedures, not all the database.
  • The query plan will only show information about the views the user has Execute access. The Tool will not show anything related to data sources. E.g. the Tool will not display the SQL queries delegated to the databases.

The main usage of this privilege are:

  1. Allow developers to connect to the production servers and troubleshoot issues, without seeing real-live data. For example, to see the full execution plans of queries.
  2. Let us say that you store all the data sources and their base views on a central database and each project is created in its own database. Thanks to the metadata privilege, the developers of each project will be able to see the full query plan, not just part of it.

Write Privilege

If you grant the privilege Write to a user/role, implicitly you are granting Execute.

Users with the Write privilege can do the following:

  • Delete the views and stored procedures of the database. A user can delete the data sources, Web services and widgets that she has created, but not the ones created by other users.
  • Modify the views and stored procedures of the database. Users can also alter their own data sources, Web services and widgets, but not modify the ones created by other users.
  • Execute INSERT, UPDATE and DELETE statements on views of this database.
  • Move elements across the existing folders of the database, except if that element is another folder.
  • Undeploy the Denodo Web services that they created.
  • Undeploy the auxiliary Web services of the widgets that they created.
  • View the VQL of the following elements:
    • Data sources, derived views, base views, stored procedures, JMS listeners, web services and widgets.

If you grant this privilege over a specific view or stored procedure instead of a database, the user will be able to do the following:

  • Delete the view/procedure. If there are other elements that depend on the one being deleted, the user needs to have Write access over these other elements as well because they will be deleted on cascade.
  • Modify the view/procedure. The user can only modify a derived view if it has the “Execute” privilege over the subviews of the view.
  • Move the view/procedure across the existing folders of the database.
  • Execute INSERT, UPDATE and DELETE statements over the view/procedure.
  • View the VQL of the element.

File Privilege

Users with the File privilege can browse through the directories listed in the dialog File privilege of the wizard Server Configuration.

Admin Privilege

This privilege can only be assigned over an entire database. Users with this privilege have the privileges Connect, Create, Metadata, Execute and Write over all the elements of that database. Besides, they can do the following tasks:

  • Set the configuration parameters of the database: I18N, cache, swap, etc.
  • Edit the description of the database.
  • Grant / revoke privileges to normal users over the elements of the database. It cannot grant the Admin privilege to other users.
  • Grant / revoke privileges to roles over the elements of the database.
  • Create / rename / drop folders.
  • List, deploy, redeploy and undeploy all the Denodo Web services and the auxiliary Web services of widgets.

A user with this privilege cannot do the following:

  • Create / delete users
  • Create / delete roles
  • Grant / revoke roles to users or other roles
  • Change users’ password
  • Create / drop databases
  • Grant Admin privileges to other users.

Insert, Update and Delete Privileges

Users with the Insert privilege can execute INSERT statements over the view.

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

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

These privileges are not applicable to stored procedures.

You can only grant these privileges over individual views, not databases. If you want to grant a user to privilege to run these statements over all the views of a database, grant her the Write privilege.

Column Privileges

When you grant the privilege EXECUTE over a view to a user or a role, this user or the users with this role can query this view to obtain all its data. With “column privileges” you can limit the fields that these users can project.

For example, let us say you have a view “employee” and you want to forbid users with the role “developer” to see the column “salary”. To do this, edit this role and for the view “employee”, click Assign column privileges and clear the check box next to the field “salary”.

With this change, the user will be able to run this query:

SELECT ename
FROM employee
But this one will fail:
SELECT ename, salary
FROM employee

If instead of making the query fail, you want to mask the values of a column, specify a row restriction with column masking (see section below).

Consider this:

  • Column privileges do not affect global administrators or administrators of the database to which the view belongs. I.e. they can project any column of the view regardless of its column privileges.
  • Column privileges do not affect the INSERT/UPDATE/DELETE statements, only the SELECT ones.

Row Restrictions

When a user/role has the privilege EXECUTE over a view, you can define a restriction over the view to restrict the rows returned to that user/role. That way, when that user/role queries the view, they will only obtain the rows that match certain criteria and/or some of the fields of some rows will be masked.

You can also specify that the results will only be filtered when the query projects certain fields.

For example, you can create a row restriction over a view “employee” to allow the users with the role “developer” to obtain only the rows that match the restriction position <> 'manager', when the query projects the column “salary”.

To create a row restriction that takes into account more complex information to decide if the result of the query is filtered or not, you can develop a custom policy. The section Custom Policies of the Developer Guide explains what they are and how to develop them.

Consider this:

  • Row restrictions do not affect users that are global administrators or administrators of the database to which the queried view belongs. I.e. no row will be rejected or masked regardless of their privileges.
  • These restrictions do not affect the write/update/delete operation. They only affect the SELECT ones.

Enforcing Column Privileges, Row Restrictions and Custom Policies

By default, Denodo only applies column restrictions, row restrictions and custom policies specified over a view for a certain user/role, when the view is directly referenced from the query.

For example, let us say you define a column restriction for the role “developer” over the view “employee”. This restriction forbids this role to project the column “salary”.

If a user with this role executes the following query, the query will fail:

SELECT ename, salary
FROM employee

But if another user created the following view:

CREATE VIEW employee_dept1 AS
  SELECT ename, salary
  FROM employee
  WHERE deptno = 1
and the users with the role “developer” have the privilege EXECUTE over the whole database or over the view “employee_dept1”, these users will be able to query this view (i.e. obtaining the field “salary”), even though this role has a column restriction defined over “employee”.

Because of this behavior, if you want to assign restrictions to users/roles over some views, do not grant them the privilege EXECUTE over the whole database. Instead, only grant them privileges over each view individually.

A user/role with column/row restrictions or custom privileges over a view is not allowed to create a view derived from this view. This means that if a user with the role “developer” runs this:

CREATE VIEW employee_new AS
  SELECT ename, salary
  FROM employee
the command will fail.

Enforce Restrictions on All Queries

If you want Denodo to always enforce the column/row restrictions and custom policies regardless of if the view is directly involved in the query or not, follow these steps:

  1. Log into the administration tool with an administrator account:

  2. Execute this from the VQL Shell:

    SET 'com.denodo.vdb.catalog.user.User.enableCheckViewRestrictionAlways' = 'true';
    

    The change is applied immediately, you do not need to restart.

  1. Choose if you want to enable this behavior over a specific database or all of them:

    1. To enable this behavior on all views of all databases, execute this:

      SET 'com.denodo.vdb.catalog.user.User.checkViewRestrictionAlways' = 'true';
      

      The change is applied immediately, you do not need to restart.

    2. To enable this behavior only on some databases, execute this:

      ALTER DATABASE <database>
      CHECK_VIEW_RESTRICTIONS { ALWAYS | DIRECT_QUERIES_ONLY | DEFAULT }
      

      For example:

      ALTER DATABASE core
      CHECK_VIEW_RESTRICTIONS ALWAYS;
      

      If you specify DEFAULT, the database will follow the behavior specified by the property com.denodo.vdb.catalog.user.User.checkViewRestrictionAlways.


After enabling this behavior, the column/row restrictions and custom policies defined over a view will always be enforced, whether the query references the view directly or indirectly. This means that even if a user with the role “developer” can query the view “employee_dept1”, the query:

SELECT * from employee_dept1
will fail because it is using the column “salary” of the view “employee”.

When this option is enabled, the user is allowed to create views over a view with restrictions if it has the right privileges (CREATE or CREATE VIEW). That is because even if the user creates the view, the query will still fail. Note that this is different from when this option is disabled; in that case, the user is never allowed to create derived views over views with restrictions.

Roles

A role is a set of access rights that we can grant to users. The benefit of assigning roles to users instead of assigning privileges is that the management of permissions is easier. If you change the privileges of a role, the changes are applied to all the users that “belong” to that role. Without roles, you would have to edit the privileges of each user.

A user can have more than one role assigned and her “effective permissions” will be the union of the permissions assigned by each role. For example, if there is a role A that grants execute permission over the database “admin” and another role B that grants execute permission over the database “tests”, a user with the roles A and B will have execute privileges over the databases “admin” and “tests”.

In addition, you can assign roles to other roles. This is called “Role inheritance”. For example, if you have the following roles:

  • A role vdp_developer with the privileges CONNECT, EXECUTE, CREATE and WRITE over the database admin.
  • A role itpilot_developer with the privileges CONNECT, EXECUTE, CREATE and WRITE over the database itpilot.

You can create a role denodo_developer that has assigned the roles vdp_developer and itpilot_developer to it. The users with this new role will have the privileges CONNECT, EXECUTE, CREATE and WRITE over the databases admin and itpilot.

The permissions assignable to a role are the same that we can assign to a user.

Virtual DataPort defines the following special roles:

  1. serveradmin is equivalent to being an administrator user of the Virtual DataPort server, except that it does not grant the privilege of connecting to Virtual DataPort via JMX. That is, a user with this role can manage databases, change settings of the Server, etc. A user with this role also needs the role “assignprivileges” (see below) to manage the privileges of users and roles.

  2. jmxadmin grants the privilege of connecting to the JMX interface of Virtual DataPort.

    You need this privilege to monitor the Server using JMX tools such as Denodo Monitor, Oracle VisualVM, Oracle Java Mission Control, Nagios, etc.

  3. allusers granted by default to all new local users. Additionally, you can automatically grant it to all users that connect to Virtual DataPort using Kerberos authentication or to a database with LDAP authentication.

  4. data_catalog_admin grants the privilege of modifying the settings of the Data Catalog. This role replaces the deprecated selfserviceadmin.

  5. data_catalog_exporter grants the privilege of exporting the results of the query, from the Data Catalog. This role replaces the deprecated selfserviceexporter.

  6. The scheduler_admin role is used by the Scheduler Administration Tool. The users that have this role assigned can perform any task in the Scheduler Administration Tool. This role is created during the installation process and cannot be modified or deleted.

    See more about this in the section Permissions of the Scheduler Administration Guide.

  7. assignprivileges grants the privilege of granting/revoking privileges to other users.

    Note

    Without this role, a user cannot grant/revoke privileges to the users/roles, not even an administrator.

    Take the following into account:

    • New administrator users have this role by default but you can revoke it from them.
    • This role cannot be modified. You cannot grant privileges or roles to it. This is why it is not listed in the “Role Management” panel, but it is listed in the “Assign roles” dialogs.
    • You can only assign it to administrators or to users that are administrators of at least one database.
    • A non-administrator user with this role can only modify the privileges of the databases for which it is an administrator.
    • Only administrators with this role can grant/revoke roles to users or other roles.
    • Only administrators with this role can modify the description of a role.

These roles are created during the installation process and cannot be modified nor deleted.