Microsoft Fabric Updates Blog

OneLake data access roles APIs announcement

Following the release of OneLake data access roles in public preview, the OneLake team is excited to announce the availability of APIs for managing data access roles. These APIs can be used to programmatically manage granular data access for your lakehouses. Manage all aspects of role management such as creating new roles, editing existing ones, or changing memberships in a programmatic way. Check out the API reference to learn more.

Let’s look at an example of adding a new role using the APIs.

The dataAccessRoles API gets and sets the role definitions for a lakehouse in bulk. To start, we want to fetch the existing role definitions for our lakehouse.

The API follows the structure of:

https://api.fabric.microsoft.com/v1/workspaces/{workspace_id}/items/{item_id}/dataAccessRoles

Where {workspace_id} is the ID of your workspace, and {item_id} is the ID of the lakehouse you are defining permissions for. Once updated the final call looks like:

GET https://api.fabric.microsoft.com/v1/workspaces/355b7f70-d3ce-4b1a-8630-5adf8b8df355/items/d753e987-5645-45b6-9f01-b248a367fabd/dataAccessRoles

After calling this API we get the role definition below:

{
    "value": [
        {
            "name": "DefaultReader",
            "id": "dfb20430-869a-4ace-a442-b633f43f90af",
            "kind": "Policy",
            "decisionRules": [
                {
                    "effect": "Permit",
                    "permission": [
                        {
                            "attributeName": "Path",
                            "attributeValueIncludedIn": [
                                "*"
                            ]
                        },
                        {
                            "attributeName": "Action",
                            "attributeValueIncludedIn": [
                                "Read"
                            ]
                        }
                    ]
                }
            ],
            "members": {
                "microsoftEntraMembers": [],
                "fabricItemMembers": [
                    {
                        "sourcePath": "355b7f70-d3ce-4b1a-8630-5adf8b8df355/d753e987-5645-45b6-9f01-b248a367fabd",
                        "itemAccess": [
                            "ReadAll"
                        ]
                    }
                ]
            }
        }
    ]
}

We can then add a new role called MarketingReader that grants users access to only the marketing table in my lakehouse.

First, let’s copy the role definition for the existing role and then make the required updates.

We want the new role to be called MarketingReader, so we make that change to the name property for the new role. Next, we only want to grant access to the marketing table, so we replace the * (which gives root level access) with the path to our table. This array can take multiple string values if you want to grant access to multiple tables from a single role.

Lastly, we want to configure the members for this new role. The defaultReader role uses dynamic role membership through the fabricItemMembers block of code. Instead, we want to give a Microsoft Entra group access to this role. To do this, we remove the fabricItemMembers block, and add a new user object to the microsoftEntraMembers array. All that’s needed is to provide the tenantId and objectId for the user or group. You can look up this information using the Microsoft Graph APIs.

With our changes complete, we now have the finalized code below.

{
    "value": [
        {
            "name": "DefaultReader",
            "id": "dfb20430-869a-4ace-a442-b633f43f90af",
            "kind": "Policy",
            "decisionRules": [
                {
                    "effect": "Permit",
                    "permission": [
                        {
                            "attributeName": "Path",
                            "attributeValueIncludedIn": [
                                "*"
                            ]
                        },
                        {
                            "attributeName": "Action",
                            "attributeValueIncludedIn": [
                                "Read"
                            ]
                        }
                    ]
                }
            ],
            "members": {
                "microsoftEntraMembers": [],
                "fabricItemMembers": [
                    {
                        "sourcePath": "355b7f70-d3ce-4b1a-8630-5adf8b8df355/d753e987-5645-45b6-9f01-b248a367fabd",
                        "itemAccess": [
                            "ReadAll"
                        ]
                    }
                ]
            }
        },
        {
            "name": "MarketingReader",
            "kind": "Policy",
            "decisionRules": [
                {
                    "effect": "Permit",
                    "permission": [
                        {
                            "attributeName": "Path",
                            "attributeValueIncludedIn": [
                                "/Tables/marketing"
                            ]
                        },
                        {
                            "attributeName": "Action",
                            "attributeValueIncludedIn": [
                                "Read"
                            ]
                        }
                    ]
                }
            ],
            "members": {
                "microsoftEntraMembers": [
                    {
                        "tenantId": "fef5ca5f-150b-4270-9c4b-55e103545490",
                        "objectId": "c3ddc490-8b9f-47c5-a6d9-a686ce64b424"
                    }
                ],
                "fabricItemMembers": []
            }
        }
    ]
}

We can then PUT the payload back to our lakehouse, updating the existing role definitions to match the ones specified in the API call.

PUT https://api.fabric.microsoft.com/v1/workspaces/355b7f70-d3ce-4b1a-8630-5adf8b8df355/items/d753e987-5645-45b6-9f01-b248a367fabd/dataAccessRoles

We have now updated our role definitions and our marketing users can start accessing the marketing table in the lakehouse.

A screenshot of a computer

Description automatically generated

Check out the links below for more information on OneLake data access roles and thanks for reading!

Related blog posts

OneLake data access roles APIs announcement

July 17, 2024 by Ye Xu

Fast Copy boosts the speed and cost-effectiveness of your Dataflows Gen2. We loaded a 6 GB CSV file to a Lakehouse table in Microsoft Fabric with 8x faster and 3x cheaper result. See our last post for details. Today, we’re excited to announce that Fast Copy in Dataflow Gen2 now supports high-performance data transfers from … Continue reading “Fast Copy with On-premises Data Gateway Support in Dataflow Gen2”

July 16, 2024 by Miquella de Boer

This guide will show you how to create a OneLake shortcut to a VPC-protected Amazon S3 bucket. Why use the On-premises-data gateway? Today, organizations are protecting data by leveraging network security capabilities like virtual networks, firewalls and virtual protected clouds (VPC). To access data securely and to provide a bridge between protected environments and Microsoft … Continue reading “Creating a shortcut to a VPC-protected Amazon S3 bucket”