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

Ongoing Maintenance

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.

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 Administration > Role Management.
2. Check the box for the role for which 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 press Ok.
6. Press Save.

Note: If a user still has metadata permission on the view, they can see that the restricted columns exist, however, they cannot execute queries that contain them. Thus, a select * from the view will fail.

Queries that do not contain the restricted columns execute successfully.

Hiding Columns a User Cannot Execute

As mentioned in the note above, a key drawback of the column level security mechanism is that users can see columns they cannot execute. This issue is also what causes a select * statement to fail if there is a column level restriction. There is no built-in method to avoid this in Denodo. If this becomes a problem, we would have to implement our own solution, like creating a selection view that limits the columns. Then adjust the role privileges to not allow metadata to the entire database and allow execution of only selected views, including the selection view that limits the columns.

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 Administration > Role Management.
2. Check the box for the role for which this restriction will apply and select Edit privileges.
3. Click the pencil in the Advanced column of the appropriate VDB.
4. Click the pencil icon in the Advanced column of the appropriate VDB.
5. Click the pencil icon in the View Restrictions column of the view on which the restriction will apply.
6. Click New.
7. Enter the restriction condition and action and press ok.
   1. In this case the condition is job_title = "Senior Editor"
   2. The Action is Reject Row
   3. Note: If the goal was to show all rows except where job_title is “Senior Editor” simply change the = to a <>.
8. Press Ok at the Assign restrictions screen and then save.

We can now see the restriction in action. When adam is logged in, notice that they see rows with job_title values of both ‘Senior Editor’ and ‘Nurse’.

Now I log in with the account that has the role “uofirestricted_rows_editors_only” and run the same query. Notice that only the rows with a job_title of “Senior Editor” are returned.