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 the Imply UI.
All the features of this section assume that Imply UI acts as a gatekeeper to the data store - i.e. users can only query the data store via Imply UI and never directly.
This can be done from the
Access tab of each. In the dashboard the access tab is in the
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
ChangeDashboards permissions set.
Similarly, a user possessing the
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.
A data cube acts as a view (in the SQL sense) allowing you to specify a row level filter and a restrict only certain columns for querying.
There are two use cases for restricting the data cube by rows or by columns:
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
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 cube (or to access to the SQL IDE, or query the data-store directly) then they 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.
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.
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 the 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.
Imagine you are running a auction system with buyers and sellers and you have a table of
auctions (with columns for
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 peoples 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.
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
SellerX- these role would be assigned to each individual seller organization (where
Xis the organization name). This role would have no permissions but would have a filter token by the name of
sellerTokenand the filter formula of
$seller_id == 's123'where
s123is the ID of said seller.
You will want to create two data cubes all on the
autions data source:
seller_iddefined allowing your internal users to query it as you see fit. This data cube would have view and edit access set to the
InternalUserrole and will not have a filter token requirement.
ExternalBuyeruser role this data cube will also have a filter token on
sellerTokenrequiring a user to belong to one of the
SellerXroles in order to query this data cube. This data cube will likely not have a dimension on
seller_idas it will always be filtered to one value and generally meaningless.
You might also want to create a similar arrangements for buyers, you can achieve that by symmetrically creating and
ExternalBuyer role and a similar data cube to the one in step 2.