Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
OneLake shortcuts serve as pointers to data residing in various storage accounts, whether within OneLake itself or in external systems like Azure Data Lake Storage (ADLS). This article looks at the permissions required to create shortcuts and access data using them.
To ensure clarity around the components of a shortcut this document uses the following terms:
- Target path: The location that a shortcut points to.
- Shortcut path: The location where the shortcut appears.
Create and delete shortcuts
To create a shortcut a user needs to have Write permission on the Fabric Item where the shortcut is being created. In addition, the user needs Read access to the data the shortcut is pointing to. Shortcuts to external sources might require certain permissions in the external system. The What are shortcuts? article has the full list of shortcut types and required permissions.
| Capability | Permission on shortcut path | Permission on target path |
|---|---|---|
| Create a shortcut | Write2 | ReadAll1 |
| Delete a shortcut | Write2 | N/A |
1 If OneLake security is enabled, the user needs to be in a role that grants access to the target path. 2 If OneLake data access roles is enabled, the user needs to be in a role that grants access to the target path.
Accessing shortcuts
A combination of the permissions in the shortcut path and the target path governs the permissions for shortcuts. When a user accesses a shortcut, the most restrictive permission of the two locations is applied. Therefore, a user that has read/write permissions in the lakehouse but only read permissions in the target path can't write to the target path. Likewise, a user that only has read permissions in the lakehouse but read/write in the target path also can't write to the target path.
This table shows the permissions needed for each shortcut action.
| Capability | Permission on shortcut path | Permission on target path |
|---|---|---|
| Read file/folder content of shortcut | ReadAll1 | ReadAll1 |
| Write to shortcut target location | Write | Write |
| Read data from shortcuts in table section of the lakehouse via TDS endpoint | Read | ReadAll2 |
1 If OneLake security is enabled the user needs to be in a role that grants access to the target path.
Important
2 Exception to identity passthrough: While OneLake security typically passes through the calling user's identity to enforce permissions, certain query engines operate differently. When accessing shortcut data through Power BI semantic models using DirectLake over SQL or T-SQL engines configured for Delegated identity mode, these engines don't pass through the calling user's identity to the shortcut target. Instead, they use the item owner's identity to access the data, and then apply OneLake security roles to filter what the calling user can see.
This means:
- The shortcut target is accessed using the item owner's permissions (not the end user's)
- OneLake security roles still determine what data the end user can read
- Any permissions configured directly at the shortcut target path for the end user are bypassed
OneLake security
OneLake security (preview) is a feature that enables you to apply role-based access control (RBAC) to your data stored in OneLake. You can define security roles that grant read access to specific tables and folders within a Fabric item, and assign them to users or groups. The access permissions determine what users will across all engines in Fabric, ensuring consistent access control.
Users in the Admin, Member, and Contributor roles have full access to read data from a shortcut regardless of the OneLake data access roles defined. However they still need access on both the shortcut path and target path as mentioned in Workspace roles.
Users in the Viewer role or that had a lakehouse shared with them directly have access restricted based on if the user has access through a OneLake data access role. For more information on the access control model with shortcuts, see Data Access Control Model in OneLake.
Shortcut auth models
Shortcuts use two authentication models with OneLake security: passthrough and delegated.
In the passthrough model, the shortcut accesses data in the target location by 'passing' the user’s identity to the target system. This ensures that any user accessing the shortcut is only able to see whatever they have access to in the target.
With OneLake to OneLake shortcuts, only passthrough mode is supported. This design ensures that the source system retains full control over its data. Organizations benefit from enhanced security because there’s no need to replicate or redefine access controls for the shortcut. However, it’s important to understand that security for OneLake shortcuts can't be modified directly from the downstream item. Any changes to access permissions must be made at the source location.
Delegated shortcuts access data by using some intermediate credential, such as another user or an account key. These shortcuts allow for permission management to be separated or 'delegated' to another team or downstream user to manage. Delegated shortcuts always break the flow of security from one system to another. All delegated shortcuts in OneLake can have OneLake security roles defined for them.
All shortcuts from OneLake to external systems (multicloud shortcuts) like AWS S3 or Google Cloud Storage are delegated. This allows users to connect to the external system without being given direct access. OneLake security can then be configured on the shortcut to limit what data in the external system can be accessed
OneLake security limitations
- In addition to OneLake security access to the target path, accessing external shortcuts via Spark or direct API calls also require read permissions on the item containing the external shortcut path.