Ontology data can be secured using object and property policies or data source policies. Both approaches support cell-level security, which is a combination of row and column level security.
As an example, consider a Passenger object type in a airline management platform with the properties User ID, Flight Number, Seat Assignment, Name, Address, and Phone Number.
VIP marking.Name, Address and Phone number contain user data, and can only be accessed by users that have the PII marking.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 data sources, 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.
Object and property security policies allow you to set view permissions on object instances and their properties to achieve cell-level permissions. These can be directly managed in the object type’s Ontology Manager view and are independent of the permissions on the backing data sources.
The visibility of an object instance is governed by its object security policy, whereas the visibility of a property value is governed by its property security policy. Mandatory and classification based access controls, as well as granular access controls, can be applied to object and property security policies. Together, they allow for cell-level security in the Ontology.
Learn more about setting up object and property security policies.
Data permissions for object types are implicitly controlled by the permissions applied to the input data sources of the object type.
Object and property security policies are recommended for managing object security in most cases. However, data source policies, which rely on multi-data source object types and restricted views, might be a better fit under the following conditions:
Datasets, restricted views and streams are the most widely used resources as input data sources for object types. Data permissions for these data sources are determined as follows:
Viewer permissions on the dataset and its transactions will have access to all object instances created from that dataset.Viewer permissions on the stream data source has access to all object instances created from that stream data source.Granular access controls refer to applying row-level security on data in datasets, or their object instances. For datasets, users can either access all or none of the rows and columns in the dataset. Similarly, users have either all or no access to the corresponding object instances and their properties. However, some use cases may require more granular object instance access control.
Restricted views can be used to apply granular access controls to achieve row-level security. Data permissions derived from input data sources can be leveraged using multi-data source object types to achieve column-level security.
Restricted views can only be built on top of datasets. No other data source types are supported.
Restricted views enable row-level access control to certain rows in a dataset 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 restricted view's input data source.
For example, a healthcare employee may be allowed to view dataset rows and object instances for patients that visit their care center, but they may be 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.
If a given dataset, care_event_info, has patient_id, doctor_id, and care_center columns, a restricted view can be built on top of it with the policy user.userAttribute('care_center') == care_center. The restricted view will only allow access to rows in care_event_info that have the same care center as the user.
Using Ontology Manager, restricted views can be selected as the input data source of an object type in the same way as a dataset.
Learn more about setting up restricted views and governing row-level permission for objects.
Multi-data source object types are only available in object storage v2.
The Ontology offers support for mapping multiple input data sources to a single object type. Such object types are referred to as multi-data source object types (MDOs).
MDOs enable you to map columns from different data sources to the various properties of an object type. This enables you to apply multiple access controls corresponding to separate input data sources, to a single object type. These input data sources can be any combination of datasets or 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 access. This access control can be supported by backing the Care Event object type with two separate input data sources and applying different access controls and permissions on each input data source. The Care Event object type has Patient ID as its primary key and is backed by data sources patient_info and care_event_info.
patient_info has the columns patient_id, name, address, contact_number, and age. This dataset has the PHI marking. Only users with access to the PHI marking will have access to the property values from patient_info.care_event_info has columns patient_id, doctor_id, and care_center. This dataset is unmarked. Users do not need access to any markings to access the property values from this dataset.These different permissions will be respected and applied to the object instance. A user will not have access to the properties mapped from patient_info, such as name, address, contact_number, and age, unless they have the PHI marking.
Learn more about setting up MDOs and governing column-level permissions for objects.