{"id":19758,"date":"2026-10-06T15:12:12","date_gmt":"2026-10-06T15:12:12","guid":{"rendered":"https:\/\/www.exam-labs.com\/blog\/?p=19758"},"modified":"2026-10-06T15:12:12","modified_gmt":"2026-10-06T15:12:12","slug":"microsoft-dp-700-onelake-shortcut-security","status":"publish","type":"post","link":"https:\/\/www.exam-labs.com\/blog\/microsoft-dp-700-onelake-shortcut-security","title":{"rendered":"Microsoft DP-700: OneLake Shortcut Security"},"content":{"rendered":"

OneLake shortcuts make data visible in Fabric without copying it, which means security has to account for two locations at once: the shortcut path where the data appears and the target path where the data actually lives. Effective access is constrained by the permissions that apply to both sides, and the authentication model changes depending on the type of shortcut.<\/p>\n

This is why shortcut security belongs inside the Microsoft Fabric engineering<\/a> architecture rather than as an isolated permission checklist. A shortcut can cross workspaces, domains, tenants, and clouds. Every one of those boundaries can change which identity reaches the source and which policy filters the result.<\/p>\n

The existing Fabric shortcuts<\/a> article provides the broader operational context.<\/p>\n

Creating a shortcut requires rights on the consumer and the target<\/h3>\n

To create a shortcut, the user needs sufficient permission on the Fabric item where the shortcut is created and read access to the target data. External sources can also require permissions in the external system or on the connection used to reach it.<\/p>\n

This prevents a user from making inaccessible data suddenly visible just because they control a lakehouse. The shortcut object is a reference, not an override of the producer\u2019s security.<\/p>\n

Deleting the shortcut is different from deleting the target. Removing the shortcut removes the reference while leaving the source data intact.<\/p>\n

Effective access is the intersection of shortcut and target permissions<\/h3>\n

When a user accesses a shortcut, the most restrictive relevant permissions apply. A user with read-write permission in the consumer but only read permission on the target cannot use the shortcut to write the target. The reverse is also true: broad target permission does not override a read-only consumer path.<\/p>\n

This intersection is a strong model because the producer does not have to surrender control simply because another workspace references the data. The consumer can add additional restrictions without widening the producer\u2019s grant.<\/p>\n

Security reviews should therefore inspect both locations. Looking only at the lakehouse containing the shortcut can miss the actual source authorization.<\/p>\n

Passthrough keeps the caller\u2019s identity at the producer<\/h3>\n

Same-tenant OneLake-to-OneLake shortcuts use passthrough authentication by default. The calling user\u2019s identity is passed to the target, so the user can only see target data they are authorized to access there.<\/p>\n

This model preserves producer-side control and avoids creating a separate shared credential. It is often the simplest approach when the producer is prepared to manage permissions for downstream users directly.<\/p>\n

The trade-off is administrative coupling: every consumer who needs access also needs suitable target-side permission.<\/p>\n

Delegated authentication changes who touches the source<\/h3>\n

Delegated shortcuts use a configured connection identity such as another user, service principal, or credential rather than the end user\u2019s identity. Same-tenant shortcuts can choose this model, while cross-tenant and external shortcuts rely on delegated authentication.<\/p>\n

The consumer can then use OneLake security to control which users see the shortcut data even when those users do not have direct access to the external or producer system. This can simplify access for large consumer populations.<\/p>\n

The security model becomes the intersection of what the delegated identity can reach at the source and what the consumer grants through OneLake security. That connection identity should therefore be treated as privileged infrastructure and rotated or reviewed accordingly.<\/p>\n

OneLake security adds table, folder, row, and column controls<\/h3>\n

OneLake security uses role-based access control to grant access to data scopes such as folders, tables, schemas, rows, and columns. It is a data-plane layer separate from workspace and item roles.<\/p>\n

For shortcut consumers in Viewer or item-read scenarios, OneLake security roles can narrow what the user sees. Admin, Member, and Contributor workspace roles have different control-plane capabilities and should not be mistaken for the same data-plane behavior.<\/p>\n

The existing workspace roles and data access<\/a> article is useful context because security mistakes often come from mixing these layers together.<\/p>\n

Some engines use delegated item-owner access instead of identity passthrough<\/h3>\n

Microsoft documents an important exception: certain query paths, including Direct Lake over SQL and T-SQL engines configured for delegated identity mode, do not pass the end user\u2019s identity through to the shortcut target. They use the item owner\u2019s identity to access the target and then apply OneLake security roles for the calling user.<\/p>\n

This means target-path permissions for the end user are not always evaluated the same way across every query engine. Security testing should therefore use the actual engine the production solution will use rather than assuming every access path behaves identically.<\/p>\n

Engine-specific identity behavior is one of the strongest reasons to test shortcuts end to end.<\/p>\n

External and cross-tenant shortcuts need explicit trust design<\/h3>\n

External shortcuts to systems such as ADLS, Amazon S3, or Google Cloud Storage use delegated connections. Cross-tenant OneLake shortcuts also require delegated authentication. The source trust boundary is therefore represented by a connection identity and its privileges.<\/p>\n

That identity should have only the source access needed by the shortcut. Granting a broad storage-account credential because it is easier can turn a narrow Fabric share into a wide source-side privilege.<\/p>\n

Private-network requirements should also be tested. Cross-tenant and external access can have different private-link limitations from same-tenant OneLake paths.<\/p>\n

Shortcut governance should include lineage, breakage, and connection ownership<\/h3>\n

A shortcut can break if its target is moved, renamed, deleted, or becomes inaccessible. Because there is no copy, downstream consumers depend directly on that target. Workspace lineage and connection ownership should make the dependency visible.<\/p>\n

The later Microsoft OneLake Shortcuts<\/a> article covers the broader shortcut lifecycle. From a security perspective, the key point is that a change in producer permission or connection credential can become a downstream availability incident.<\/p>\n

The strongest shortcut design documents who owns the target, who owns the connection, who grants consumer access, and how changes are communicated across that boundary.<\/p>\n

Test the effective user experience, not only the configuration screen<\/h3>\n

Security should be validated with representative identities: a workspace admin, contributor, viewer, delegated user, cross-tenant user where applicable, and the service identity used by scheduled workloads. Confirm both allowed and denied operations through the real query engines.<\/p>\n

This catches subtle cases where the configuration looks correct but an engine uses a different identity path. It also verifies that row or column restrictions survive shortcut traversal.<\/p>\n

OneLake shortcuts are powerful precisely because they let Fabric treat remote data as part of one namespace. The security design has to preserve the producer\u2019s boundaries while making that unified view useful to consumers.<\/p>\n

Connection ownership should survive employee turnover. Delegated shortcuts that depend on a personal organizational account can become fragile when that user changes role or leaves. Where supported and appropriate, service principals or managed operational identities can create a more durable trust relationship, provided their privileges are reviewed and rotated like any other credential.<\/p>\n

Write access deserves stricter review than read access. A shortcut can expose a target for writes when both the shortcut path and target permissions allow it. That means a consumer-side workspace can become a route for modifying producer data. Many sharing scenarios only need read access, and the security model should grant write capability only when the business process explicitly requires it.<\/p>\n

Column- and row-level security interactions should be tested with the actual delegated model. Microsoft documents supported combinations and limitations for delegated shortcuts, including differences between producer-side and consumer-side row restrictions. Complex RLS\/CLS designs should therefore be validated with representative users rather than inferred from a permission matrix.<\/p>\n

Caching can create another operational dimension. Shortcut caching improves repeated access for supported external data, but security and freshness expectations must remain aligned with the source. Teams should understand whether a permission or source change becomes visible immediately or only after cached data expires or is reset.<\/p>\n

Finally, the consumer should not treat the shortcut as ownership transfer. The producer still controls the source lifecycle. Contracting between teams should cover schema change, path change, retention, incident communication, and deprecation so a technically valid shortcut does not become an unmanaged dependency.<\/p>\n

Access reviews should include the shortcut as a dependency, not just the target. A user may lose direct access to the producer but retain access through a delegated shortcut if the consumer-side role still permits it. That can be the intended design, but reviewers need to understand the delegated path rather than assuming source ACL review alone covers every consumer.<\/p>\n

Audit evidence should connect shortcut administration with data access. Fabric audit logs can record control-plane changes such as shortcut creation or security-role updates, while OneLake diagnostics can record data access. Together they help answer both \u201cwho changed the trust path?\u201d and \u201cwho used the data after that change?\u201d<\/p>\n

Decommissioning shortcuts should be handled like dependency removal. Before deleting or redirecting a target, identify downstream workspaces, semantic models, notebooks, and external tools that rely on the path. Because shortcuts deliberately remove copies, a producer-side change can have immediate impact across many consumers. Controlled deprecation is therefore part of shortcut security and availability.<\/p>\n

A final production check should confirm both positive and negative access. Test a user who should read, a user who should be denied, a service principal used by automation, and the query engine that will serve the data. Security is strongest when the team can demonstrate the effective result instead of relying only on the configuration screens that appear correct.<\/p>\n","protected":false},"excerpt":{"rendered":"

OneLake shortcuts make data visible in Fabric without copying it, which means security has to account for two locations at once: the shortcut path where the data appears and the target path where the data actually lives. Effective access is constrained by the permissions that apply to both sides, and the authentication model changes depending […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-19758","post","type-post","status-publish","format-standard","hentry","category-general"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t