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! 🙌

🔐 Direct Lake on SQL Endpoint: The security gap is closing

A common trap: with SSO enabled, Direct Lake reads data using the viewer’s identity, not the semantic model owner or Service Principal.

Security becomes more complex when the architecture spans producer, consumer, and reporting workspaces, with OneLake shortcuts and separate groups for control-plane and data-plane access.

Direct Lake on OneLake handles cross-workspace authorization more natively through OneLake roles. The SQL Analytics Endpoint has historically required additional alignment across users, groups, artifacts, and shortcut paths.

The good news: Microsoft has redesigned the SQL Endpoint integration with OneLake security, providing lower latency, better nested-group support, fixes for Service Principal limitations, and User Identity mode as the default.

The SQL Endpoint experience is becoming more aligned with native OneLake security. The gap is closing.

I’ve documented the architecture, shortcut scenarios, permission model, SPN considerations, and Delegated versus User Identity modes here:

Fabric Community Blog: https://community.fabric.microsoft.com/t5/Fabric-platform-Community-Blog/Direct-Lake-on-SQL-Endpoint-OneLake-Security-Delegated-vs-User/ba-p/5358560

GitHub: https://github.com/ajit503/fabric-field-notes/blob/main/direct-lake-on-sqlep-onelake-security/direct-lake-on-sqlep-onelake-security.md

Is the new default enough, or should SQL Endpoint security remain a separately validated path in producer-consumer architectures?

#MicrosoftFabric #PowerBI #DirectLake #OneLakeSecurity #DataEngineering