Forum Discussion
Identity setup nuances | Semantic Model | Fabric-native architecture
Hi,
I’m mapping out enterprise CI/CD and security patterns for a Fabric-native Direct Lake semantic model (over a SQL Endpoint over Fabric Warehouse). Looking to perspectives/validation of these working assumptions (based upon my research)?
Workspace Identity: It perfectly handles outbound reads secret-free but must be enabled per workspace, but it does not cover inbound automation (XMLA/REST APIs). This implies that as a developer one is not needed to explicitly set authentication in semantic model settings.
ALM & Pipelines: Fabric Deployment Pipelines require manual connection remapping. Workspace Identity does not migrate with the model and must be independently provisioned in Dev, QA, and Prod.
DQ Fallback: If the engine falls back to DirectQuery against the SQL endpoint, does it require a separate explicit credential (like an SPN/Service Account), or does Workspace Identity cover both paths seamlessly? I see that Workspace Identify should suffice for both paths
'appreciate and pointer and experience sharing.
Thanks!
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.
4 Replies
Please find the answers below to the best of my known capability.
1. For the workspace identity. I think that applies as long as you have created the semantic model under the context of that workspace identity or you take it over with the workspace identity. You can also use a single workspace identity across multiple workspaces. You will just have to add that workspace identity to each workspace where you want it to work.
2. With regard to the ALM and pipelines. You can use it as mentioned before with the same workspace identity across multiple workspaces.
3. With regards to the DQ fall back, my understanding is this always uses the users. Details when querying the semantic models.
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.
