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:
- 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.
- 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 theAccessVisualization
permission.SellerA
,SellerB
, ...,SellerX
- these roles are assigned to each individual seller organization (whereX
is the organization name). This role has no permissions but has thesellerToken
filter token and the$seller_id == 's123'
filter formula wheres123
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
andseller_id
defined, allowing your internal users to query it as you see fit. This data cube has view and edit access set to theInternalUser
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 asellerToken
filter token requiring a user to belong to one of theSellerX
roles in order to perform queries. This data cube will likely not have a dimension onseller_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.