Restricted Views

Overview

Markings and roles provide powerful access controls, but some situations require more granular permissioning. For example, it may be insufficient or inappropriate to grant access to all objects of a certain type; some object types may need to surface different objects to different users, as when a company limits its sales representatives to viewing customers at their assigned branch. Restricted Views can provide this additional level of access control.

Users interact with Restricted View resources in Foundry, and Restricted Views are powered by Granular Permissions. Restricted Views limit dataset access to only the rows that a user has permission to see. A Restricted View is built on top of a backing dataset and cannot be used as an input for transforms. The policy for a Restricted View determines the specific rows a user can see and is typically defined by a user with the Owner role upon creation of the Restricted View. After creation, the Restricted View can be used as the backing data source for an object type in your Ontology. For example, if one row in the Restricted View is represented by one object in the Ontology, the Restricted View would control what objects users can see based on the object type the Restricted View is backing.

Restricted View policies

The policy is the core of a Restricted View. A Restricted View policy is a set of rules and/or logical operators that compare different user attributes, columns, and/or values to determine which rows the user can see. Restricted View policies are flexible and can support a range of comparisons and terms such as:

• User attributes: User ID, username, group ID, group name, Organization Marking ID, Markings, user email, etc.
• Column name: A column in the Restricted Views backing dataset.
• Specific value: A string, Boolean, number, or array.

Most, if not all, policies will involve at least one term that is compared with a user attribute. At least one such term is necessary for user-based permissioning.

Design Restricted View policies

Assume that you want to build out an object type that surfaces different objects to different users. The first step is to design your Restricted View policy. Consider the following questions:

• How do you want to restrict access to the data in your Ontology?
• What user attributes can you use in the policy?
• On which columns in your data could your policy depend?
• Which Markings propagate through the pipeline but could be unmarked when creating the Restricted View?
• How will you grant object permissions to new users?

In the example below, the Restricted View policy includes two rules that can be applied:

Recommendations

We recommend the following guidelines when designing a Restricted View:

• Keep it simple: Before creating a Restricted View, write down the policy you want to enforce. Determine the minimum set of conditions required for that policy. The more complex the policy, the harder it will be to manage and verify.
• Make sure policy columns are non-null: Rows with null values in a policy column will be inaccessible to all users. Having null values in the policy column will also cause Phonograph syncs for that table to fail.
• Leverage the pipeline: To reduce the complexity of policies that don't fit well with the current data shape or fields, use the pipeline to compute columns that will make policy-writing easier. Try to handle complexity in the pipeline rather than in the Restricted View policy.
• Consider using a dedicated policy column: Changes made to columns in the backing dataset referenced in your policy may break the policy assumptions. To protect a policy from this risk, consider separating out the logic that decides the policy and creating a dedicated column (or columns) for the policy to reference.
• Use attributes: Attribute-based policies can often be the simplest option. Attributes can be pulled from SSO or posted via a user manager.
• Use Markings: Apply a Marking to the backing dataset of your policy to guarantee its protection and ensure that it is only visible to users who have access to the Marking. You can stop inheriting the Marking in the Restricted View since the Restricted View already controls which rows a user can see. If the sensitive data has been marked at the source and the Marking has been correctly propagated, there should be no need for a new Marking when creating a Restricted View.

After you’ve determined the design of your Restricted View policy, make any pipeline and Project changes needed to power it. With a Restricted View policy and pipeline in place, you can move on to creating your Restricted View.

Create Restricted Views

Users with an Owner role or the necessary permissions can create Restricted Views downstream of a dataset with a right-click contextual action:

The Restricted View creation dialog has the following steps:

1. Save as: Choose a name and location where the Restricted View will live in the file system.
2. Compose a granular policy: Define the policy statement(s) that will determine which rows or objects users are able to see when accessing the Restricted View or object.
3. Review access requirements: Review the existing file and transaction-level Markings on both the upstream dataset and downstream Restricted View. With appropriate permissions, you can un-mark (remove) Markings from the Restricted View.
4. Summary: Review your selections before the creation and initial build of the Restricted View.

Save as

Name your Restricted View and select a save location. Typically, you will want to save your Restricted View in a different Project to the input dataset so that users consuming the Restricted View can all have View permissions on the downstream Project. Alternatively, you can save the Restricted View in the same Project as the input dataset and utilize Markings to protect the input dataset.

Compose a granular policy

You can create rule-based policies using the terms below:

• User attributes: User ID, username, group ID, group name, Organization Marking ID, Markings, user email, etc.
• Column name: A column in the Restricted Views backing dataset.
• Specific value: A string, Boolean, number, or array.

When referencing a user, group, or Organization, the policy requires the unique identifier (UUID) in both the policy column and the policy definition. Specifying names instead of IDs is not supported to prevent renaming-related issues.

Review access requirements

Users that should only access sensitive data through a Restricted View should not have access to the upstream dataset. In this step, you can review the access requirements for both the dataset and the Restricted View you are creating. If you have appropriate Marking permissions, you can remove inherited Markings from the Restricted View and/or apply Markings to the upstream dataset.

Summary

The Summary presents the final proposed access controls for both the dataset and the Restricted View. If you are satisfied with the Summary result, click Create to start an initial build of the Restricted View.

When the Restricted View is created, a build schedule will be automatically created in the background that will rebuild anytime the input dataset updates.

Review the management documentation on how to use Restricted Views to back object types.

Create Marking-backed Restricted Views

You can create a Restricted View based off of a dataset with a column of Markings. Each row will only be visible to users with the necessary Marking access. For example, in the Restricted View below, a user needs both A1 and A2 to view the first row, and needs B1 to view the second row.

Follow these steps to create a Marking-backed Restricted View:

1. Prepare a dataset with one or more Marking columns that will be secured as a Restricted View. Each cell must contain either a STRING Marking ID or a STRING ARRAY of Marking IDs. Learn more about the expected format of the upstream dataset.
2. Annotate each Marking column by going to the COLUMNS tab of the Dataset Preview interface, selecting the column, clicking “Add typeclasses”, and entering marking_type.mandatory. This step is not necessary for granular permissions to work, but some interfaces in Foundry use this as a hint to render the column more appropriately.

3. Create the Restricted View off of the dataset. The left side of the policy rule should be “user’s Markings”. For the right side, select “Columns” and select the Marking column. If you have multiple columns, create a rule for each one and combine them with AND or OR rules as desired.

Expected format of the upstream dataset

The dataset from which a Restricted View is created must contain a column of Marking IDs.

• These IDs are universally unique identifiers (UUIDs).
• The column must be either type STRING (and each cell has a single Marking ID) or type STRING ARRAY (and contain a list of Marking IDs).
• You may have more than one column of Marking IDs.
• You may mix Markings and Organizations in the same column.

For example, the following dataset contains a single security Marking per row:

As another example, this dataset contains lists of Markings. The sample CSV below can be uploaded directly to Foundry, though you will need to manually modify the inferred schema by going to Details > Schema and changing "type": "STRING" to "type": "ARRAY, "arraySubtype": { "type": "STRING" }.

Add Restricted View to Marketplace product

Use Foundry DevOps to include your Restricted Views in Marketplace products for other users to install and reuse. Learn how to create your first product.

Supported features

Only string and boolean constants are supported. Constants can only be compared to fields (columns) or "the user’s groups" user property. Marketplace currently does not support multiple field-constant comparison conditions using the same field.

Adding Restricted Views to products

To add a Restricted View to a product, first create a product and then select the Restricted view content type as below.

Adding a Restricted View to a product packages the Restricted View's policy, not the data.