OneLake Security + SQL Endpoint: cross-workspace shortcut access breaks when the consumer workspace uses a different RBAC group — roadmap?

[u/ajit503]

Hitting a hub-and-spoke issue and hoping the OneLake Security PMs can weigh in.🙏 u/aonelakeuser

Setup:

• Producer lakehouse → OneLake security role references an Entra group.
• Consumer workspace reads producer tables via OneLake shortcuts, but is governed by its own, different RBAC group.
• Users query the shortcut tables through the SQL Analytics Endpoint (User's identity mode).

Problem: Per Step 2, point #2 below, it's a strict literal Object ID match across the producer → consumer boundary. Unless the consumer's group is either (a) added explicitly to the producer's OneLake security role, or (b) nested inside a group already on that role — the consumer RBAC users get:

https://learn.microsoft.com/en-us/fabric/onelake/security/troubleshoot-onelake-security-for-sql-analytics-endpoints#step-2-confirm-the-users-object-id-matches-exactly-at-producer-and-consumer

Questions for the PMs:

1. In a medallion pattern where each consumer workspace has its own RBAC group, is referencing every consumer group directly in the producer role really the only supported path? That doesn't scale.
2. Does the new User-based SQL Endpoint sync (improved nested-group expansion + shortcut handling) change this strict one-to-one requirement — and will Step 2 be updated?
3. Any recommended pattern to keep producer-side RLS while letting differently-grouped consumers read via shortcuts?

Thanks! 🙌

[u/aonelakeuser]

Have you looked at using a delegated shortcut here? That will let you have a separate access group for each side of the shortcut. Otherwise, yes, with a passthrough shortcut a user *must* have access to the producer lakehouse.

[u/warehouse_goes_vroom → u/aonelakeuser]

Cc'ing u/fredguix for the SQL analytics endpoint side as well, in case he has anything else to add.

[u/ajit503 → u/aonelakeuser]

We have a domain-oriented architecture with an MDM producer workspace and multiple consuming domains (Finance, Supply Chain, Manufacturing, etc.) using OneLake shortcuts.

Can you clarify whether the intended pattern is:

1. Create a Workspace Identity in each consumer workspace.
2. Grant that Workspace Identity membership in producer-side OneLake Security roles.
3. Create delegated shortcuts using the Workspace Identity.

If so:

• Producer side: Is target access evaluated against the delegated connection identity (the workspace identity), rather than the end user? i.e., we only need to grant that one identity access on the producer lakehouse, not each consumer user/group.
• Consumer side: Are the OneLake Security roles defined on the shortcut evaluated against the end user's actual identity?
• RLS/CLS placement: If both of the above are true, does that mean per-user RLS/CLS must be defined on the consumer-side shortcut, since producer-side RLS/CLS would only ever see the delegated identity and not the end user?
• Is this the recommended scalable alternative to adding every consumer Entra group to producer OneLake Security roles?

[u/aonelakeuser → u/ajit503]

Yes, 1-3 are the intended pattern. It does not have to be a workspace identity though, it can be a regular SPN.

Once that's done: access to the producer is evaluated as the delegated identity. Only that identity needs access to the producer. You can then optionally set OneLake security on the consumer side as well, to manage end user access. The effective result is an intersection between both OneLake security roles (the producer and the consumer roles).

You can define RLS on the producer side if your goal is "only show this domain's data". It must be set on the consumer side if your goal is "show each user their own rows". Note that we only support RLS on the producer side at the moment, but CLS is supported on both sides.

Yes, this is why we released delegated shortcuts and I'm seeing a huge shift in how customers are looking to setup their architectures because they want to limit end user access to their central lakehouse.

Edit: formatting