Access control

Ensuring that the right people in the right roles have access to the right data (and more importantly do not have access to the wrong data) is crucially important. This section will detail the access control functionality built into Pivot.

All the features of this section assume that Pivot acts as a gatekeeper to the data store - i.e., users can only query the data store via Pivot and never directly.

For Imply Private, most of this section is only relevant if are running Pivot in user enabled mode.

Data cube and dashboard access control

It is possible to define access permissions for each data cube and dashboard.

This can be done from the Access tab of each. In the dashboard the access tab is in the Options panel.

It is possible to restrict access to only specific people or specific roles.

The edit access permissions of individual data cubes and dashboards only apply if the user has the ChangeDataCubes and/or ChangeDashboards permissions set. Similarly, a user possessing the AdministerDataCubes and/or AdministerDashboards permissions will be able to see and change all data cubes and/or dashboards respectively.

When a data cube or dashboard is created the default access controls are set according to what is configured by the Default data cube view access, etc. in the settings.

Restricted edit mode for data cubes

In some cases, it may be desirable to give users a more limited ability to edit aspects of a data cube, e.g. to allow users to modify dimensions but not to change the title or description.

This can be done by configuring the data cube options using the restrictedModeProperties key.

Row and column level restrictions

A data cube acts as a view (in the SQL sense) allowing you to specify a row level filter and restrict only certain columns for querying.

There are two use cases for restricting the data cube by rows or by columns:

1. Fine tuning the user experience with a data cube - maybe you want the user to focus on a meaningful subset of the data and tailor the dimensions and measures that a user sees accordingly.
2. Letting certain users see only a specific slice of data for security reasons - maybe the user should not be able to see all the roles, or perhaps some columns contain sensitive data that certain users should not have access to.

If you are in the second use case then you must ensure that the users who you are trying to restrict do not have edit permissions to the data cube as otherwise they can just edit the restrictions out. Furthermore you most likely want to restrict these users from accessing the data manager or the SQL IDE by not giving them those permissions.

Any user who should be restricted from accessing all data for security reasons should only ever have the AccessVisualization and possibly QueryRawData permissions.

Row level restriction

It is possible to set a subset filter that would be silently applied to every query made through this data cube (this includes any dashboard tiles and Explain queries based on this data cube).

The subset filter is a Plywood expression and is editable in the Advanced tab of the data cube edit screen.

If a user does not have permissions to edit or create data cubes (or to access the SQL IDE, or query the data-store directly) then they will effectively be restricted to only seeing the data matched by the subset filter expression.

It is possible to make this subset filter dynamic with the aid of filter tokens.

Column level restriction

Only the columns that are used in the dimensions and measures defined in the data cube will be queryable through the data cube. If there are columns in your data that you want to restrict the user from querying you can do so by not having any dimensions or measures defined that use that column.

Token based row level access control

Sometimes it is necessary to have the row based access control be dynamic given the users role. For example, you might be using a single source in Imply to provide analytics to users from a variety of organizations, and each organization's users should only be allowed to see data that pertains to their organization.

This is the use case that filter tokens are designed to solve.

The filter token system consists of two parts. The first part are filter tokens themselves that are just a name and filter formula pair that live on the user roles. The second part are the data cubes that can be configured to require filter token of a given name to be queryable. A user possesses all the filter tokens that are on all the roles that the user is assigned to. When a user goes to query a data cube that has a filter token requirement the user must possess exactly one filter token of that name (otherwise no queries will be issued). The filter expression from that filter token will then be applied to all queries.

Filter token example

Imagine you are running an auction system with buyers and sellers and you have a table of auctions (with columns for buyer_id and seller_id) that contains a record of every closed auction. You want to offer some sellers a way to see their own data in Imply, but they should not be able to see other people's data. At the same time your internal users should be able to see all the data.

Let's look at how you might go about setting this up. Note that any suggested names are only there to provide clarity, you are welcome to use your own names.

Step 1 - the roles

You will want to create the following roles:

• InternalUser - this role would be assigned to all the internal users of your organization. There might be multiple internal user roles to serve your internal needs.
• ExternalSeller - this role would be assigned to all the external sellers of your platform. It will contain only the AccessVisualization permission.
• SellerA, SellerB, ..., SellerX - these roles would be assigned to each individual seller organization (where X is the organization name). This role would have no permissions but would have a filter token by the name of sellerToken and the filter formula of $seller_id == 's123' where s123 is the ID of said seller.

Step 2 - the data cubes

You will want to create two data cubes all on the auctions data source:

• One data cube for yourself and your internal users This data cube will have dimensions for buyer_id and seller_id defined, allowing your internal users to query it as you see fit. This data cube would have view and edit access set to the InternalUser role and will not have a filter token requirement.
• One data cube for the buyers. This data cube will have view access from the ExternalBuyer user role. This data cube will also have a filter token on sellerToken requiring a user to belong to one of the SellerX roles in order to query this data cube. This data cube will likely not have a dimension on seller_id as it will always be filtered to one value and generally be meaningless.

Next steps

You might also want to create similar arrangements for buyers. You can achieve this by symmetrically creating an ExternalBuyer role and a similar data cube to the one in step 2.