Data Authorizers
    • 19 Dec 2023
    • 3 Minutes to read
    • Dark
      Light
    • PDF

    Data Authorizers

    • Dark
      Light
    • PDF

    Article summary

    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.).

    Data Authorizers Graphic.png

    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.

    Some of our Authorizers are currently supported with a default "User" Identity Workspace only. For additional information, reach out to our Support Team.

    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).

    image.png

    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.

    image.png

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

    image.png

    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.

    image.png

    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.


    Was this article helpful?