notebookutils.runtime.context['userName'] doesn't work for Workspace Identity or Service Principal
Please make notebookutils.runtime.context return the name of the Workspace Identity or Service Principal when running a notebook under such identities. userId is populated with the object id of the identity. But the userName is empty - please fix.
Support semantic model creation with Workspace-level Private Link
Semantic models are a core enterprise BI artifact. Workspace‑level Private Link with blocked public access is mandatory for regulated industries (banking, financial services, public sector). Without supported Semantic Model creation, Fabric cannot be adopted as a production‑ready BI platform in these environments. This capability is critical for enterprise and regulated customers evaluating Microsoft Fabric as a strategic analytics platform. Current state documented here: Supported scenarios for workspace private links - Microsoft Fabric | Microsoft Learn The main concern with workaround: Temporary public access or item‑creation order workarounds are non-deterministic, not automatable, and violate compliance requirements.
Improve Connection Discovery and Reuse Across Fabric Experiences
Description: Enhance the Fabric user experience by displaying all available and accessible connections in a consistent drop-down list across Dataflow Gen2, Notebooks, and other Fabric workloads. This would allow users to easily discover and reuse existing connections instead of recreating them, resulting in a more intuitive and streamlined onboarding experience. Benefits: Simplifies connection management and improves user experience. Reduces duplicate connection creation and accelerates onboarding to Fabric.Reuse Existing Fabric Connections in Dataflow Gen2, Notebooks
Today, users can create and manage reusable Snowflake connections in Fabric under Manage Connections and Gateways. However, when creating a Dataflow Gen2, or Notebook, existing Snowflake connections are not surfaced for selection, requiring users to recreate the same connection within the Dataflow experience. This creates unnecessary duplication, increases administrative overhead, and introduces the risk of inconsistent connection configurations across Fabric workloads. Here are the details of what I already tried: I created a Snowflake connection in Microsoft Fabric using Key Pair authentication. The connection is visible under Manage Connections and I am the owner. The Dataflow Gen2 is in the same workspace and I am also the owner of the Dataflow. However, when creating a Snowflake source in Dataflow Gen2, the existing connection is not listed. The UI only shows "Create new connection" and does not provide an option to select the existing Snowflake connection. The authentication method in Dataflow Gen2 is also set to Key Pair. Requested Enhancement: Allow Dataflow Gen2, Notebook to discover and reuse existing Fabric-managed Snowflake connections that the user owns or has permission to use, similar to the connection reuse experience available in other Fabric workloads. Benefits: Accelerates customer onboarding and time-to-value by enabling immediate reuse of existing Snowflake connections across Fabric workloads. Reduces administrative overhead and configuration errors by eliminating duplicate connection creation and management. Improves governance and consistency through centralized connection and credential management across Fabric experiences.
Enabling Keyless Authentication - Workload Identity Federation for GCP from Microsoft data platform
Category: Feature Request / Security & Authentication Impacted Services: Azure Data Factory (BigQuery Linked Service), Power BI (Desktop & Service), Microsoft Fabric (Lakehouse, Dataflows Gen2, Data Pipelines), Power Query Connectors Executive Summary Currently, Microsoft’s Google BigQuery integrations in Azure Data Factory (ADF), Power BI, and Microsoft Fabric rely exclusively on Service Account JSON Keys for machine workloads or interactive User OAuth / Single Sign-On for human users. There is no native support for Workload Identity Federation (WIF) between Microsoft Entra ID and Google Cloud Platform (GCP) for non-interactive machine workloads. In enterprise environments—particularly where Google BigQuery endpoints are publicly accessible—forcing the use of static, long-lived JSON key files presents a severe credential leakage risk, increases management overhead, and violates zero-trust principles. We request Microsoft prioritize adding native Workload Identity Federation (Machine-to-Machine) support across ADF, Power BI Desktop/Service, and Microsoft Fabric (including Lakehouse). Security & Risk Exposure Analysis 1. Data Exfiltration Risk via Public Endpoints: Many enterprise BigQuery instances rely on GCP’s public API endpoints, protected primarily by IAM authentication and network controls. Storing a service account key file creates a single point of failure: if a key with BigQuery Data Viewer or BigQuery Admin roles is leaked, an attacker can query or exfiltrate sensitive data from any public IP address without triggering perimeter network alerts. 2. High Credential Blast Radius: Unlike short-lived OIDC tokens (which expire within 1 hour), GCP Service Account JSON keys remain valid until explicitly revoked. If exposed via build logs, code repositories, unencrypted backups, or compromised storage, the exposure window lasts indefinitely. 3. Operational Overhead & Rotation Risk: Storing keys in Azure Key Vault mitigates storage risk but does not eliminate lifecycle risk. Automated rotation of GCP JSON keys across Key Vault, ADF, Lakehouse shortcuts, and Power BI datasets is fragile and regularly breaks automated data pipelines. Proposed Solution: Universal Machine-to-Machine Federation Establish a trust relationship between GCP Workload Identity Pools and Microsoft Entra ID (Azure AD), allowing Azure workloads to dynamically request short-lived, auto-rotating GCP access tokens via OIDC without ever generating or storing private keys. Requested Functionality by Ecosystem: Azure Data Factory (ADF Linked Service): Add a new option under Authentication Type: Workload Identity Federation / Entra Managed Identity. Allow ADF runtime engines to pass System-Assigned or User-Assigned Managed Identity tokens to GCP’s Security Token Service (STS) to exchange them for temporary Google Service Account tokens. Power BI Ecosystem (Desktop & Service): Desktop: Enable Power Query connection dialogs to accept Entra Service Principal or Managed Identity authentication for BigQuery models. Service: Support Entra Managed Identity / Service Principal credentials under Data Source Credentials in workspace settings to ensure unattended, scheduled background dataset refreshes run without requiring active user sessions. Microsoft Fabric Ecosystem (Lakehouse, Dataflows Gen2, Data Pipelines): Support Entra Managed Identity / Service Principal credentials directly within Fabric Lakehouses when creating shortcuts or ingesting BigQuery tables. Ensure native Workload Identity Federation is built directly into Fabric Data Pipelines and Dataflows Gen2 to secure modern background ETL/ELT workloads. Reference Documentation Power Query Google BigQuery Connector Docs: Microsoft Docs Azure Data Factory Google BigQuery Connector Docs: Microsoft Docs Google Cloud Workload Identity Federation Overview: GCP Docs Fabric - https://learn.microsoft.com/en-us/fabric/data-factory/connector-google-bigquery?source=recommendations Business & Security Benefits Keyless Security Architecture: Completely eliminates long-lived service account key files and manual key rotation overhead across all data environments. Compliance Alignment: Enables enterprise compliance with SOC 2, ISO 27001, and Zero-Trust standards regarding identity management. Reduced Vulnerability Radius: Even if a public BigQuery endpoint is exposed, access relies exclusively on transient OIDC tokens tied strictly to the runtime identity of the ADF pipeline, Lakehouse job, or Power BI refresh engine.Fabric User Assigned Managed Identities
Workspace Identity is a great addition, but I think UAMI could complement it rather than replace it. Some advantages of UAMI would be: - A single identity could be shared across multiple workspaces. - An identity could be scoped more narrowly than a workspace, for example to a specific item or even a single folder within a Lakehouse. - Greater flexibility overall, since the scope could be either broader or narrower than a Workspace Identity. - Similar to how SPN provides more flexibility than WI today. - Benefit of UAMI over SPN: no credentials to handle. It would basically provide the same flexibility as an SPN, just without the credentials.Interactively run notebook as Service Principal, Workspace Identity or Managed Identity
Please make it possible to interactively run a Notebook as a Workspace Identity, Service Principal or Managed Identity. Purpose: This would allow us to connect to resources that our personal user account doesn't have access to. This would allow us to interactively test notebooks using the Workspace Identity, Service Principal or Managed Identity before we include the notebook in a pipeline. This way, we could test: the identity's access to data sources and the notebook code's functional compatibility with running as SPN/WI/MI (because not all notebook functionality like semantic link is compatible with SPN, we'd like to be able to test this interactively before including the notebook in a pipeline).
