Skip to main content

Access Policies

Access Policies contain column- and row-level rules that determine which rows and columns of a given Data Pool are accessible. A Policy can have multiple rules, and row-level rules can use static or dynamic values to determine which rows are accessible.

Column-level rules​

The “columns” field in an Access Policy determines which columns of a Data Pool the policy allows access to. You can define a policy that allows access to certain columns and denies access to others. This can be useful when you have sensitive data that only certain users or groups should be able to access. For example, you might want to restrict access to financial data or personally identifiable information (PII).

The "columns" array accepts a list of strings that correspond to the column names. These names should align with the column names in the Data Pool. The example below shows the column section of the policy as it appears in the Console, as well as its JSON representation.

{
  "columns": ["taco_name", "taco_total_price"]
}

Allowing access to all columns

Alternatively, you can grant access to all columns in a Data Pool. The example below shows a Policy as it appears in the Console, as well as its JSON representation, that allows access to all columns.

{
  "columns": ["*"]
}

Row-level rules​

Row-level rules in an Access Policy determine which rows of a Data Pool the Policy gives access to. You can define a Policy that allows access to certain rows and denies access to others. This can be useful when you have data that is only relevant to certain users or groups. For example, you might want to restrict access to data that pertains to a specific department or region.

When setting up row-level rules, the allowed rows are determined by a set of filters. Each filter consists of a column name, an operator, and a value. The column name must match the name of a column in the Data Pool.

The example below shows a row-level rule as it appears in the Console, as well as its JSON representation. It allows all rows where “restaurant_name” equals “Farolito”.

{
  "rows": [
    {
      "column": "restaurant_name",
      "operator": "EQUALS",
      "value": "Farolito"
    }
  ]
}

Row-level rules with dynamic values

Row-level rules can also have dynamic values. Let's explain what that means by changing our example. Instead of hard-coding “Farolito”, let's use ${{ restaurant_name }}. This is a placeholder that means, “get this value from the Application's access token.”

{
  "rows": [
    {
      "column": "restaurant_name",
      "operator": "EQUALS",
      "value": "${{ restaurant_name }}"
    }
  ]
}

The behavior we want to express has the same result: when queries are made against this Data Pool, we will only return data for a single restaurant; however, instead of hard-coding a restaurant name, we are now looking it up from Application's access token.

In this example, different customers would have their specific restaurant name encoded in the access tokens they use to query data. The token would be requested from a trusted backend (your server) with the specific restaurant name added. Because the restaurant name is cryptographically signed in the access token, even if the token is compromised, a different restaurant or a malicious user would be unable to use the token to query any data except for the restaurant data the token was created for.

Read the guide on Building multi-tenant applications.

Assigning Access Policies to Propel Applications​

When you create Access Policies for a Data Pool, you can then assign them to Applications.

A diagram demostrating the relationship between a Data Pool, an Access Policy, and an Application

A Data Pool can have multiple Policies, and each Policy can be assigned to multiple Applications, but an individual Application can be assigned at most one Policy per Data Pool.

A diagram demostrating the relationship between a Data Pool, two access Access Policies, and multiple Applications

Note that Access Policies do not take effect until access control is enabled on a Data Pool. This means you can start prototyping with Access Policies disabled; then, once you get things working, you can set up Access Policies and enable access control.

Metrics and Data Pool Access Policies​

In Propel, Metrics belong to Data Pools, and so a Data Pool's Access Policies govern if an Application can query a Metric or not. When a Data Pool has access control enabled, an Application can only query a Metric if its Access Policy allows access to the columns that make up that Metric.

For example, if the “Revenue” Metric is defined as the sum of the “total_price” column, an Application will need a policy that allows access to the “total_price” column to be able to query the “Revenue” Metric. The same is the case for any Metric Filter or dimension.

Creating and assigning Access Policies via the Console​

To create Access Policies via the Console, navigate to the Data Pool for which you need to create a policy. Then, click on the "Access Policies" tab.

Screenshot of the Data Pool detail page pointing to the Access Control tab.

You'll want to create the Access Policies first, then enable access control to avoid breaking your app. To create your first policy, click on “Add new policy”.

Screenshot of Access Policies page indicating where to create a new one.

On the “Create new policy” page, you can define the column and row-based access controls for your Data Pool. In the example below, we will demonstrate how to limit access to a subset of columns and rows, using static and dynamic values. We will use the TacoSoft data from the Quickstart as a reference.

After defining the column- and row-based access controls, you can assign one or many Applications to the Policy. However, each Application can only have one Policy assigned per Data Pool.

Screenshot of the page to create a new Access Policy.

After creating the Policy, you can view the list of Policies for that Data Pool. From this view, you can easily assign Applications to Policies.

Once you have your Policies ready you can enable Access Control to start enforcing them.

Warning

If you are using dynamic values for your row-based access controls, ensure that you are passing the values in the token as described in the Multi-tenant access control section. This will prevent accidental access restrictions to your application when enabling the Access Controls.

Screenshot of Access Policies of a Data Pool.

You are all set with your Access Policies!

API reference documentation​

You can create the Access Policies, assign Access Policy to an Application, and enable access control on a Data Pool via the API. Below is the relevant API documentation for working with Access Policies.

Queries​

Mutations​