There are two primary forms of access control and permissioning for Ontology data (object types): object input datasources and granular access controls.
The Check access panel in the sidebar can be used to check someone's access to a Workshop or Slate application, including access to dependent object types, their datasources, and granular access controls. For more information, see the Check access panel documentation.
Some property values refer to data stored in additional resources outside of the Ontology. The access control mechanisms described in this section only control the visibility of the property values, but not the visibility of those additional resources. For example, a media reference property can refer to a media item stored in a media set. If the media set has different permissions from the object type, then it is possible for a user to not have access to a media reference property, but still be able to fetch the media item directly from the media set. Therefore, it is important to ensure that the additional resources are configured with the appropriate permissions when using them in the Ontology.
Data permissions for object instances in the Foundry Ontology are controlled by the permissions applied to the input datasources. Object types in the Foundry Ontology can have three types of resources as their input datasources: Foundry datasets, Foundry restricted views, and Foundry streams. Development is ongoing to support additional datasource types in the Ontology.
Viewer permissions on the dataset will have access to all the object instances created from that dataset.Viewer permissions on the stream datasource has access to all the object instances created from that stream datasource.The most common Ontology input datasources are Foundry datasets; for these datasets, users can either access all or none of the rows and columns of the dataset, and similarly either all or none of the corresponding object instances and their properties. However, some use cases and workflows may require more granular object instance access control than all-or-nothing for a datasource or its corresponding objects.
To this end, Foundry restricted views (RVs) offer row-level access controls and Multi-datasource object types (MDOs) provide a solution for column- or property-level access controls.
Foundry Restricted Views (RVs) support on top of Foundry streams is in the beta phase of development and may not be available on your enrollment. Functionality may change during active development. Contact Palantir Support to request access to this feature.
Foundry Restricted Views (RVs) enable row-level access controls to certain rows in a Foundry dataset or a Foundry stream and the corresponding object instances created from those rows. Access to an object instance with a specific primary key is governed by who can access that specific row in the input Restricted View datasource.
For example, a healthcare employee may be allowed to view dataset rows and object instances containing PHI for patients that visit their care center, but restricted from viewing data for patients that only visit other care centers, even if both types of data exist in the same dataset and object type.
Using the Ontology Manager, Restricted Views can be selected as an input datasource of an object type in the same way as a Foundry dataset.
Learn more about setting up RVs and governing row-level permissions for object instances.
Multi-datasource object types (MDOs) are only available in Object Storage V2.
The Foundry Ontology offers support for mapping multiple input datasources to a single object type. Such object types are referred to as multi-datasource object types (MDOs).
MDOs enable you to map columns from different datasources to the various properties of an object type. This, in turn, enables you to apply multiple access controls (corresponding to separate input datasources) to a single object type. These input datasources can be any combination of Foundry datasets or Foundry Restricted Views.
For example, for a given care event object type, some healthcare employees may require access to object properties containing personal health information (PHI), while other employees should not have this access. This access control can be supported by backing the Care Event object type with two separate input datasources and applying different access controls and permissions on each input datasource. These different permissions will be respected and applied to the object instance, such that a user will not have access to the properties mapped from an input datasource if that user does not have access to the input datasource.
Learn more about setting up MDOs and governing column-level permissions for object instances.