Forum Discussion
Identity setup nuances | Semantic Model | Fabric-native architecture
Hi ankurarora1418 ,
Your understanding is mostly accurate. Workspace Identity enables secret-free access for Fabric native Direct Lake semantic models over Fabric Warehouses or SQL Endpoints, but this is limited to outbound data access. Inbound operations such as XMLA, REST APIs, or CI/CD automation will still require their own authenticated identities.
For deployments, Workspace Identity must be set up and granted permissions in each environment, as it is a workspace level configuration and does not automatically transfer with the semantic model.
With Direct Lake fallback to DirectQuery, Workspace Identity is designed to facilitate access to the underlying Fabric data source, provided the necessary permissions are in place on the Warehouse or SQL Endpoint. However, please note that fallback execution context may differ depending on configuration, so it should not be assumed that it always operates under the querying user's identity.
Thank you.
Hi ankurarora1418 ,
Your understanding is mostly accurate. Workspace Identity enables secret-free access for Fabric native Direct Lake semantic models over Fabric Warehouses or SQL Endpoints, but this is limited to outbound data access. Inbound operations such as XMLA, REST APIs, or CI/CD automation will still require their own authenticated identities.
For deployments, Workspace Identity must be set up and granted permissions in each environment, as it is a workspace level configuration and does not automatically transfer with the semantic model.
With Direct Lake fallback to DirectQuery, Workspace Identity is designed to facilitate access to the underlying Fabric data source, provided the necessary permissions are in place on the Warehouse or SQL Endpoint. However, please note that fallback execution context may differ depending on configuration, so it should not be assumed that it always operates under the querying user's identity.
Thank you.
Thanks for the response v-tejrama
For deployments, Workspace Identity must be set up and granted permissions in each environment, as it is a workspace level configuration and does not automatically transfer with the semantic model.
➡️ So, in a scenario involving a native deployment pipeline deploying a Semantic model to a higher environemnt Fabric workspace (QA to Prodcution), is it fair to assume that semantic model would need no additional configuration as long as the target workspace (in this case a Production workspace) has workspace identify setup?
As long the the workspace identity setup is configured for the workspace (which would be a one time manual activity as you mentioned), the model would not any manual intervention in terms of data source configuration. Is that inference valid?
With Direct Lake fallback to DirectQuery, Workspace Identity is designed to facilitate access to the underlying Fabric data source, provided the necessary permissions are in place on the Warehouse or SQL Endpoint.
➡️What permissions are being referred to here? May I request an example?
However, please note that fallback execution context may differ depending on configuration, so it should not be assumed that it always operates under the querying user's identity.
➡️As per what I have noticed, RLS scenarios may cause a DirectQuery fallback for a semantic model setup as DirectLake on SQL mode. However, under this scenario I have seen the querying user's identify is maintained and RLS rules implemented at Fabric Warehouse (WH) level were honored (thereby implying the identity reached the WH), though I'm not sure whether the fallback really happened). Any thoughts ?
Thanks!
Hi ankurarora1418 ,
Thanks for reaching out to the Microsoft fabric community forum.
Based on Microsoft documentation, Workspace Identity is a workspace level identity that is associated with a Fabric workspace and is configured separately for each workspace. To use Workspace Identity for accessing resources, the identity must be granted the appropriate permissions on the target resources that it needs to access.For your question about permissions, Microsoft documentation explains that Workspace Identity can obtain Microsoft Entra tokens to access a resource after the Workspace Identity has been granted the required permissions on that target resource. In the context of a semantic model that relies on a Fabric Warehouse or SQL endpoint, the Workspace Identity would therefore need the necessary permissions on those underlying resources.
Regarding Direct Lake fallback, Microsoft documentation states that Direct Lake on SQL endpoints can fall back to DirectQuery in certain scenarios, including when SQL based security is detected or when querying tables that enforce row level security (RLS) in the SQL endpoint. During fallback, queries are sent to the SQL analytics endpoint or Warehouse.
The documentation reviewed does not provide additional details about the identity context used during all Direct Lake to DirectQuery fallback scenarios, so I am unable to provide further guidance on that aspect based solely on Microsoft documentation.
Documentation:
- Workspace identity - Microsoft Fabric | Microsoft Learn
- Authenticate with Microsoft Fabric workspace identity - Microsoft Fabric | Microsoft Learn
- How Direct Lake works - Microsoft Fabric | Microsoft Learn
Thank you.