Access control

It is important to be able to restrict access to data. This section explains access control functionality built into Pivot.

The features discussed here assume that Pivot acts as a gatekeeper to the data store, that is, users can only query the data store via Pivot and never directly.

For Imply Enterprise (formerly Imply Private), the information presented in this section only applies if you are running Pivot in user enabled mode.

Data cube and dashboard access control

You can define access permissions for each data cube and dashboard from the Access tab. In the dashboard, open the Options panel to locate the Access tab.

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 or ChangeDashboards permissions set. Similarly, a user possessing the AdministerDataCubes or AdministerDashboards permissions will be able to see and change all data cubes or dashboards respectively.

When you create a data cube or a dashboard, the default access controls are determined by the Default data cube view access configurations in the Settings tab.

Restricted edit mode for data cubes

In some cases, you may need to limit a user's ability to edit aspects of a data cube; for example, to allow a user 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. Refining 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.

For the second use case, make sure that the users you want to restrict do not have edit permissions to the data cube. Otherwise, they can edit the restrictions. By not giving users edit permissions, you can restrict their access to the data manager and the SQL IDE.

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

You can only query the columns used in the dimensions and measures defined in the data cube. To restrict a user from querying certain columns in your data cube, do not define any dimensions or measures 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 can set this up. Note that any suggested names are only there to provide clarity.

Set up roles

Create the following roles:

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

Set up data cubes

Create two data cubes on the auctions data source:

• One data cube for yourself and your internal users. This data cube has dimensions for buyer_id and seller_id defined, allowing your internal users to query it as you see fit. This data cube has view and edit access set to the InternalUser role and does not have a filter token requirement.
• One data cube for the buyers. This data cube has view access from the ExternalSeller user role. This data cube specifies a sellerToken filter token requiring a user to belong to one of the SellerX roles in order to perform queries. 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.