Data Access Control

Data Policy Concepts

For data tables in Data Library, data access control on row-level is achieved by a creating a Data Policy. Thereby, different users and/or groups of users can be given access to different rows of a data table. A data table can have one or several Data Policies and the combined restriction of all Data Policies will be used when deciding which data rows, a user is allowed to access.

For example, if a temporary exception from the general data policy is needed, then the exception can be applied as a second data policy, rather than editing the general data policy. Thereby, when the exception is no longer needed, it is enough to delete the second, temporary data policy.

Data policies can be given customized names, as a way of describing what the policy is for and keeping different policies apart.

Data Policy cannot be used for controlling access to different columns of data; the data table will have the same data schema regardless of who the user is.

NOTE: Data Policy cannot be applied to Workbook Local data tables.

Folder Permissions for Data Table Users

Data access control by using Data Policy is meaningful only for users that have Read-Only access to the data table, since Write access would allow modification of the Data Policy and would allow making a copy of the data table including connection settings details. Read-Only access is set in the Folder Permission settings. For any data table that needs a Data Policy, best practice advice is to place the data table in a folder where the folder permissions are set to Allow - Everyone - Read, or an even stricter setting in case there are some users that should be entirely blocked from
using the data table. Administrators will always have full access to the data table, regardless of what the Folder Permission settings are. Users that have Read-Only permission are unable to edit, copy, or move the data table.

Folder Permissions for Data Table Owners

To apply a Data Policy and/or link a Permission Table to a data table, the user needs Write permissions on the folder where the data table exists. Any user with Write permissions will be able to load any rows from the data table while editing the Data Policy and can specify other usernames and/or group names to preview which data rows
the user will be able to reach. The user tasked with creating and managing a data table that has a Data Policy, must be trusted with access to all of the data.

Permission Tables

A Data Policy specifies logic rules for how data rows should match on username and/or group membership of the user accessing the data table. In case the data table does not contain columns that can be compared directly to usernames and group names, the data can be linked to one or multiple Permission Tables. A Permission Table is created like any other data table and the data source can be, for example, an Excel spreadsheet, a database table, or a CSV file. The purpose of the Permission Table is to associate usernames and/or groups with values found in the data table that needs a Data Policy. For example, a Permission Table can list usernames in one column and customer account names in another column. A Permission Table must also contain one or several columns with values that are also found in the data table, that work as join keys between the data table and the Permission Table. An example of a suitable such key column could be a column containing customer account id:s, or project id:s.

A table that serves as a Permission Table must have the same Folder Permission settings as the actual data table. Since the data in a Permission Table will decide how usernames and/or user groups are associated with values in the data, it is of critical importance that the Permission Table is protected from unauthorized editing. However, while
the Permission Table needs protection from unauthorized editing, its content cannot be considered a secret; anyone with Read access to the actual data table must also have Read access to the Permission Table.

Exporting Data Policy

When exporting a data table that has a data policy, you have the option of exporting the policy and any Permission Table along with the data table. The policy and Permission Table will then be imported along with the data table.

Given this sample Data table:

CustomerAccountID	CustomerName	Sales
123	AAA	100
234	BBB	110
345	CCC	120
456	DDD	130
567	EEE	140
678	FFF	150

And this sample Permission Table:

CustomAccountID	AccountManager
123	john@acme.foo
234	mary@acme.foo
345	john@acme.foo
456	mary@acme.foo
567	paul@acme.foo
678	paul@acme.foo

The data table and Permission Table are linked based on CustomerAccountId.

Special Functions for Data Policy Access Rules

Panopticon supports the following macros, and their parameters, for data policy access rules definition.

Function	Description	Example
USER_IS(username)	Validates the user identity by comparing the lowercase user name, stripped of domain, with a static string or column value.	USER_IS(“john.doe”) USER_IS([UserNameColumn])
USERNAME_IS(username)	Validates the user identity by comparing the unmodified user name, including the domain, with a static string or column value.	USERNAME_IS(“John.Doe@acme.org”) USERNAME_IS(“Acme\John.Doe”) USERNAME_IS([UserNameColumn])
USER_MEMBER_OF(group)	Validates user group membership by checking the user groups of the logged in user for the existence of a static string, or column value.	USER_MEMBER_OF(“SalesTeam”) USER_MEMBER_OF([AccountRegion])

Here are data policy access rule examples:

USER_IS([AccountManager])

USER_MEMBER_OF("Managers")

USER_MEMBER_OF("Managers") AND USER_MEMBER_OF("IndiaTeam")

USER_IS([AccountManager]) OR USER_MEMBER_OF("SalesLead")

USERNAME_IS([UserNameColumn])

Intellectual Property Rights Notice | Technical Support