Data Authorizers

Data Authorizers Overview

Consistently protecting the same data assets across different databases is a challenge that many data owners struggle with. Often, there is a lack of transparency around the authorizations that are enabled due to the different layers of permissions that can surround the database. The Authorization Platform manages access to data, providing the following main benefits:

• Unified Access Management - Manage access to data objects using a unified interface that can provide consistent access decisions.
• Fine-grained access solution - Use an access solution that supports fine-grained access controls, both on a row and column level.
• Central enforcement layer - Implement a central enforcement layer for all data access.
• Centralized authorization management while enabling organizations to connect third party plugins. Using PlainID's Data Authorizers helps enforce organizations' businesses Access Policies throughout the technological stack, enforcing row level, column level, and cell level access to data stored on various platforms (such as Denodo, Google BigQuery, Trino, etc.).

The Authorization Platform offers unique support for database-adaptive access, including permissions according to some or all columns and/or rows based on the user's Identity. The Data Authorizers use the Policy Resolution endpoint (see Policy Resolution in the Developer Portal) to determine how the Organization's Authorization Policies should be applied.

For more information, see Managing Data Authorizers.

Setup for Asset Types

Building Policies for Data Access Enforcement

Data enforcement is based on two levels of decision:

• Row level
• Column level

To build Policies for data, both row and column levels should be considered. When setting up the building blocks for fine-grained data access in the Authorization Platform, the following structure must be followed:

• Asset Type for row level access control
• Asset Type for column level access control

The supported types of Asset Attributes for both row and column level attributes are String and Numeric.

For example, in the following table, the relevant Attributes to be used to enforce access on the data are branch (String type) and balance (Numeric type).

Asset Type or Row Level Access Control

For each table in which a row level access decision needs to be provided, an Asset Type needs to be created. The Asset Type should contain the Attributes needed to enforce access for the specific table and the Asset Type is used for data filtering field should be set to Yes. Assets are managed in the Authorization Request.

Therefore, the Asset Type for this table will contain these two Asset Attributes, as shown below:

The Policy decision from the Asset Types configured for data filtering (in the Asset Types is used for data filtering field) is used to build the “where” clause of the query. The Row level Asset Type can be created through the Authorization Platform UI.

Asset Type for Column Level Access Control
The Asset Type to support column level access can be either an External Asset Source or a PlainID Asset Source. As a best practice, we recommend using External. One column level Asset Type should be created per Environment. This Asset Types supports column level access to multiple tables in your data source. There are no constraints on the name of this Asset Type, but the Asset Types is used for data filtering must be set to No, as shown below.

After creating the Asset Type, you need to create Asset Attributes for the column level access. Any Asset Attribute based on which you wish the Access Decision to be calculated. These additional Asset Attributes are dictated by the customer’s use case. For example, if you wish to include “classification” (private, confidential, etc.) to filter the columns, you will need to create an Asset Attribute classification.

The Policy decision from the Asset Type that is not used for data filtering, is used to build the selectable columns of the query. The Asset Type to support column level access can be either an External Asset, or a PlainID Asset Type. As a best practice, we recommend using External. One column level Asset Type should be created per environment – this Asset Type will support column level access to multiple tables.

There are no constraints on the name of this Asset Type.