Skip to main content

Securing table data with row access controls

In today's data-centric landscape, precise data access control is vital for maintaining security and integrity. The row-based access feature offers granular control over data visibility, allowing organizations to specify which users or user groups can view particular rows within a table. This technical guide provides a structured overview of implementing row-based access, ensuring your organization maximizes the security and efficiency of its data management processes.

Important

This feature is available exclusively in private installations and is currently in Private Preview. Please contact your Customer Success Director to request access and discuss implementation.

What is row based access?

Row-based access offers granular permission settings within datasets, allowing you to control table data visibility according to user roles, thereby enhancing security and usability. Once enabled, this feature ensures that users only see data they are authorized to view based on the implemented policies. Importantly, their access is determined by these policies and not by their general permissions on the dataset.

Requesting support team to create the ddw-security-constraints dataset

To implement row-based access, begin by contacting your support team to create the ddw-security-constraints dataset. This dataset is crucial for managing application-wide configurations and is controlled by the data.world support team. Users needing to edit this dataset should request specific access permissions.

Important

Please note that ddw is a special organization that is used to manage application wide configurations and is managed by the data.world support team. Therefore, you will only be granted limited access in this organization.

  • Contact the data.world support and ask them to create the following dataset in the ddw organization. Request full access to the dataset so that you can add files to the dataset.

    Note

    Only users who need to edit the ddw-security-constraints dataset need to have full access to the dataset.

    ddw-security-constraints_dataset.png

Preparing to enable row based access

To configure row-based access, gather the following crucial information: Group ID, User ID, and table IRI.

  • GROUP ID: ID of the group which will be granted access.

    • Format: <org_ID>/<group_ID>

    • Example: For a group URL like https://8bank.app.data.world/marketing-org?id=23d153f0-b892-43e8&sub=groups&tab=members, the Group ID is marketing-org/23d153f0-b892-43e8.

    • For out-of-the-box groups use the following values:

      • <org_ID>/members: All members in the organization.

      • <org_ID>/admins: Members in the out-of-the-box admin group.

      • <org_ID>/authors: Members in the out-of-the-box author group.

  • USER ID: ID of the user who will be granted access.

    • Example: janedoe

  • TABLE IRI: IRI of the table for which you want to apply the policies. Execute the following SPARQL query on your dataset to extract the IRI details.

    PREFIX dwec: <https://dwec.data.world/v0/>
PREFIX dwo: <https://ontology.data.world/v0#>
SELECT ?tablename (STR(?table) AS ?iri)
WHERE 
{    
    ?table a        dwec:DwTable;
    dwo:name ?tablename
}
ORDER BY ?tablename

    From the query results page, right-click the value in the iri column and click Copy Link Address.

    copy_table_iri.png

    An example table IRI might be https://8bank.app.linked.data.world/d/ddw-books-tables/tbl-books.

  • ROW POLICY DEFINITION: Decide which rows should be visible based on column values.

    • Example: If a table has a published column with the year 1977, configure the policy to only show those rows for users. If multiple conditions are applied, such as published = 1977 and author = 'Stephen King', users will see a combined set of rows that meet either condition.

Configuring the policy file

Creating a policy file in .ttl format (for example, policy.ttl) incorporating grants, scopes, and applications, which is then integrated within your environment.

  • Grants define the conditions under which data is accessible (for example, published = 1977, or weight <=70).

  • Scopes pinpoint which data tables these conditions apply to.

  • Applications map these conditions to specific users or groups, ensuring precision in data access.

PREFIX dw: <https://data.world>
PREFIX policy: <https://data.world/policy/1.0/>
PREFIX ex: <https://myco.com/rules/>

#Define the IRI of the dataset in which the table resides.
PREFIX ds: <ttps://8bank.app.linked.data.world/d/ddw-catalogs-tables/>

###############################################################################
# Define the GRANTS
# What do we check before givingDefine the GRANTS, specifying which rows in the tables the user can access to a row?.
# Determine the conditions to check before granting access, based on the values of specific columns.
ex:published77 a policy:Grant ;
  policy:where "published = 1977" ;
  .

ex:published05 a policy:Grant ;
  policy:where "published = 2005" ;
  .

###############################################################################
# Define the SCOPES of the policy.
# SetsDefine the SCOPES for the policy by specifying the IRI of the tables to apply the row access policy.
# The policy can target either a single table or multiple tables. The policy only applies if the column being checked is present in the table.
# These tables may be located within the same dataset or distributed across different datasets.

ex:bookTableex:PublicationsTables a policy:Scope ;
  policy:table ds:tblds:<https://8bank.app.linked.data.world/d/ddw-books-tables/tbl-books> ;
  policy:table ds:<https://8bank.app.linked.data.world/d/ddw-magazine-tables/tbl-magazines> ;
  .


###############################################################################
# Define the APPLICATIONS for the policies. 
# Apply GRANTS, SCOPES to agents (to a specific member);
ex:Booksjanedoe a policy:Application ;
  policy:appliesToAgent "janedoe" ;
  policy:scopedTo ex:bookTableex:PublicationsTables ;
  policy:grantAccess ex:published77 ;
  .
# Apply GRANTS, SCOPES to groups (to a specific group in the organization);
ex:BooksStewards a policy:Application ;
  policy:appliesToGroup "marketing-org/23d153f0-b892-43e8" ;
  policy:scopedTo ex:bookTableex:PublicationsTables ;
  policy:grantAccess ex:published05 ;
  .

Uploading the policy file to the ddw-security-constraints dataset

Upload the completed policy.ttl file into the ddw-security-constraints dataset. This action integrates the row access policies within your environment.

  • Add the policy.ttl file you created earlier in the ddw-security-constraints dataset.

    add_file_to_dataset_row_access.png

Testing row based access

In the example implementation explained earlier, users will have the following experience while accessing the table in the dataset.

  1. When user Jane Doe accesses the table, she will only see the rows where the publish year is 1977.

  2. When any user in the Steward group accesses the table, they will only see the rows where the publish year is 2005.

FAQ

  • What happens if a user doesn't match any policy application?

    Users who do not match any specific policy application will not be able to see any rows. Once a policy is enforced, data visibility is restricted strictly to users who meet the criteria of at least one policy application. They will only see those rows to which they have been explicitly granted access.

  • How is data access handled for users in multiple groups, each with distinct table access?

    If a user belongs to different groups with varying access rights to the same table, they will experience combined access. The policies allow these grants to stack, meaning the user will view the union of all rows they have access to, based on all applicable group memberships (all applied conditions will be ORed together).

  • Why am I seeing all rows in a table instead of a subset?

    If you observe full access rather than restricted visibility, check that the configuration file is correct and that the table IRI is precise.

In this section: