Restricted Views

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: Properties of the user viewing the data.
• 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.

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.

User attributes

Below is a list of supported user attributes in Restricted View policies:

• User ID: A unique ID generated by Foundry for each user.
• Username: A unique ID provided by the user's identity provider at login.
• Group IDs: The IDs of all the groups that have the user as a member (direct and inherited).
• Group names: The names of all the groups that have the user as a member (direct and inherited).
• Authorized group IDs: This is an advanced concept related to scoped sessions. Contact your Palantir administrator if you plan to use Restricted Views with scoped sessions.
• Organization Marking IDs: The Marking IDs of all Organizations that have the user as a member (primary and guest). Note that these are Marking IDs which are UUIDs, not Organization IDs that start with ri.multipass..organization.
• Marking IDs: The IDs of all Markings that the user has permission to view.
• Custom attributes: Any custom attributes configured by your identity provider in Control Panel.

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 user attributes, column names, and specific values. See Restricted View policies for more information.

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 a Marketplace product [Beta]

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.

Add and merge restricted views to a branch [Beta]

Support for restricted views in branching version control is in beta. Learn more about branching. To enable this feature on your enrollment, contact your Palantir representative.

Add a restricted view on a branch

To add a restricted view to a branch, select the branch in the dropdown menu. Then, use the Add resource option to add the restricted view to the branch. This allows you to build or modify the policy of the restricted view by adding it as a modified resource into your branch.

This is a necessary step because by default, accessing a restricted view on a branch displays content from the main branch. However, if you are already on a branch and edit the restricted view’s policy or markings, then it will automatically be added to the branch with those edits. Note that builds are automatically triggered when a restricted view is added to the branch.

By default, owners and editors have the ability to add a restricted view to a branch. Owners can edit the policy and markings to add the branch restricted view, while editors can only build a restricted view. This allows editors to add the restricted view to their branched workflow and test it without needing ownership of the restricted view.

View a branched restricted view

The permissions on a branched restricted view are the same as the parent restricted view. If you can view the original restricted view, you can view its branched restricted views. Note that if the upstream dataset on a branch restricted view has different markings, then a viewer may be able to see previously-restricted data.

Propagate a restricted view downstream

If the restricted view is updated on a branch, object types backed by the restricted view will need to be indexed on the branch to reflect these changes. Within Ontology Manager, use the Index object type option on the top banner to index the object on the branch. Once indexed, Workshop modules referencing these objects and Ontology Manager will reflect the restricted view changes on the branch.

Approve a restricted view change

Restricted views are currently being integrated with the Approvals application. Currently, changes to a branched restricted view made by an owner does not require approval and are marked as automatically approved.

Merge in a branched restricted view

The permissions for merging a restricted view on a branch are the same as branching integrations in other applications: only the creator of the branch can merge a restricted view.