Securing an operational application

After building your data foundation, you can start building out your ontology and a Flight Alert Inbox application on top of it. The goal is to provide operational users with a valuable workflow while also making the security legible and easy to maintain.

Object data inherit dataset permissions

With the backing data already transformed, you can create four objects in your ontology: Flight, Flight Alert, Delay, and Aircraft. To do this, create new object types and pick the backing datasets you already built for each object. During this process, you will be mapping columns in your dataset to properties in the new object type. Each column in the backing dataset will become a property in the new object type, and each row in the backing dataset will become an instance of the object type. Therefore, the data inside an object type will be protected by the permissions of the backing datasets.

For the Aircraft object, the data is protected by the permissions on the /Sky Industries/Aviation [Ontology]/aircraft dataset. Therefore, a user in the Aviation [Ontology] - Viewer group on the Aviation [Ontology] Project will be able to see the data in the Aircraft object.

After creating the necessary objects, you can create the necessary link types between the Objects based on how they are related to each other. Below is our ontology.

To support your full workflow, you will want to add writeback for some of your objects. Writeback allows editing of the existing property values (for example, to fix incorrect values or to update a status property) but also, and perhaps more importantly, allows for the capture of new data and decisions, which enables compounding of value over time.

To do this, simply generate a writeback dataset in the Editor section. We recommend putting the edited dataset in the same ontology project as the backing dataset (e.g. Aviation [Ontology]), so that the permissions on the object are uniform. The recommended way to edit an object is by using Actions, which can also be called via APIs. Below is our Flight Alert object with a writeback dataset.

Granting users access to your ontology data will all be managed by the groups you created and applied in your data foundation. For example, you would only have to add a new user into the Aviation [Ontology] - Viewer group for them to see the data for all four objects: Flight, Flight Alert, Delay, and Aircraft.

Editing the ontology

You can control who can edit the configuration of specific object types in your ontology by using Ontology roles. Ontology roles enable applying roles directly on each Ontology resource (object types, link types, and action types). For example, in order for a user to edit the Flight Alert object in the Ontology, they only need to have Ontology Editor role on the Flight Alert object and do not require any permissions on the backing datasource. They can manage these permissions in the Security section on each object type.

Restricting instances of objects

Later we decide that we want to incorporate Passenger data, so we integrate and build out a Passenger data pipeline.

For compliance reasons, we might want operational users to only see passengers in the country they’re in (US users can only see US passengers, German users can only see German passengers, etc.). Because our Object type is backed by a dataset, its permissions are tied to the dataset as a whole. If we want to restrict permissions on individual rows, we need to back our object type by a Restricted View, which is a row-permissioned view of a single dataset.

When creating our Restricted View, we will need to do the following prerequisite steps:

1. Create a global group, passenger-data-global-access, to give all the administrative users access to the global Passenger data.
2. Confirm our users have the necessary geographic User attributes (e.g. location:country - US)
3. Create a project for the Restricted View, called Customer Information [Restricted], that will have all the Restricted Views related to customer information now and in the future. This will allow us to permission access to the Restricted View separately from the backing input dataset.

After we complete the prerequisites above, we can go ahead and create the Restricted View. Go to the input dataset resource and select Create restricted view, as highlighted below.

The Restricted View wizard will walk you through all the steps. Save the Restricted View in the new Customer Information [Restricted] project we created earlier.

The policy is the core piece of the Restricted View, since it determines what rows users will be able to see. In this example, we will want to:

• Only show rows where the user’s attribute location:country matches the value in the country column in our dataset, OR
• Show all the rows when the user is a member of the passenger-data-global-access group.

Below is what the specific policy would look like:

After the wizard is complete, the Restricted View will be built. After it is built, we can use our Restricted View to back our Passenger object. The object type will automatically inherit the Restricted View policy and use that policy to restrict which object instances a user can see.

Adding data to the Data Catalog

The Data Catalog is a browsable view of curated content in Foundry. While every dataset in Foundry can be analyzed, assuming you have the correct permissions, the datasets in the Data Catalog have been identified as the most useful or relevant to the users and are collected there for easy access.

After building out your ontology, it is recommended that you add all your ontology datasets to the Data Catalog. In particular, the ontology writeback datasets should be added to your Data Catalog, since they are the canonical source for the object data.

Giving users access to your application

After the Flight, Flight Alert, Delay, Aircraft, and Passenger objects were built, we went ahead and built out the Flight Alert Inbox application for the Operations center by following the Workshop documentation. Given we want to separate who can edit the Flight Alert Inbox application from those that can edit the ontology data, we will create a new Oroject specifically for the Flight Alert Inbox application. The new project will be called Flight Alert Inbox.

To access this Project a user must meet all access requirements. Since there are no Markings associated with the Project, users need a role and must be a member of the Sky Industries Organization.

Operational consumers will be added to the Aviation [Ontology] - Viewer group to see the Flight, Flight Alert, Delay, Aircraft, and Passenger data and the Flight Alert Inbox - Viewer group to see the Flight Alert Inbox application.

Application developers will be added to the Aviation [Ontology] - Viewer group to see the Flight, Flight Alert, Delay, Aircraft, and Passenger data and the Flight Alert Inbox - Editor group so that they can edit the Flight Alert Inbox application.

Pipeline developers will be added to the Aviation [Ontology] - Editor group to edit the Flight, Flight Alert, Delay, Aircraft, and Passenger dataset and either the Flight Alert Inbox - Viewer so they can see the workflow downstream of their changes.