Skip to main content

Application Identity and Access Management

Application identity and access management is a critical aspect of building secure and scalable applications in Microsoft Fabric. This design area supports authentication, authorization, and role delegation between services, users, and applications within a landing zone and across tenants.

Identity and Access Patterns in Microsoft Fabric​

Cloud-native applications—whether developed on Data Pipelines, Notebooks, or via APIs like the XMLA endpoint—require clearly defined identity mechanisms. Especially when building APIs (e.g., with GraphQL), developers must register applications in Microsoft Entra ID and use delegated or application permissions.

Authentication and Authorization Standards​

Microsoft Fabric supports standard protocols like:

  • OAuth 2.0 and OpenID Connect for interactive and delegated access.
  • JWT (JSON Web Tokens) for token-based authentication between services.
  • SAML for legacy integrations.
  • Workload identity federation via OpenID Connect for secure CI/CD integrations.

Microsoft Entra Application Registration for APIs​

When building APIs such as GraphQL endpoints:

  • Register your application in Microsoft Entra ID.
  • Define required API permissions (delegated or application).
  • Assign consent through admin or user flow.
  • Use the App ID and secret/certificate to authenticate securely.

See Microsoft identity platform documentation for guidance on app registration and token acquisition.

Managed Identities vs. Service Principals​

  • Managed Identities (system- or user-assigned) simplify authentication to other Azure services without storing credentials.
  • Service Principals require secret/certificate management and are typically used for external or long-lived automation.

Use managed identities whenever supported—especially in pipelines, dataflows, and REST/CLI interactions with the Fabric workspace or underlying Azure resources.

Common Scenarios​

Use CaseIdentity Option
Notebook accessing Data WarehouseSystem-assigned MI
GraphQL API secured with EntraApp registration + secret
CI/CD pipeline deploying DataflowsFederated identity (OIDC)
Spark Job writing to Blob StorageManaged identity + RBAC

Workload Identity Federation and Multi-Tenant Scenarios​

Workload Identity Federation for CI/CD​

Modern CI/CD pipelines, especially with GitHub Actions, can securely authenticate against Azure without storing credentials. This is done using Workload Identity Federation, which enables a GitHub workflow to exchange a short-lived OIDC token for an Azure AD token, eliminating the need for service principal secrets.

Setup Steps:

  1. Create a user-assigned managed identity in Azure.
  2. Enable federated credentials for that identity, linked to your GitHub repo/environment.
  3. Assign the necessary RBAC roles for your workload (e.g., Data Factory Contributor, Fabric Admin).
  4. Configure your GitHub Action using azure/login with the correct tenant, client ID, and federated subject claim.

🔗 Federated Identity Setup for GitHub

Benefits:

  • Credential-free deployments
  • Built-in lifecycle management
  • Short-lived tokens enhance security

Use this approach to deploy pipelines, manage workspace assets, or automate dataset refreshes securely.

Multi-Tenant Fabric Deployments​

Microsoft Fabric supports scenarios where application teams operate across multiple Microsoft Entra tenants. This is common in B2B setups, partner-hosted solutions, or cross-organization data collaboration.

Design Considerations:

  • Use App Registrations in the target tenant for APIs and data access (e.g., GraphQL, REST endpoints).
  • Register external guest users (B2B) in the platform tenant if cross-tenant access is required.
  • Ensure Entra ID Conditional Access policies allow federated or external identities to authenticate and acquire tokens.
  • Configure Microsoft Entra ID enterprise applications for GraphQL or workspace apps in the consuming tenant.
  • Apply Granular RBAC roles to manage access boundaries across tenants.

When using managed identities, be aware that these are scoped to a single tenant. For multi-tenant automation, you must use app registrations with consented permissions or federated workload identities configured per tenant.

Scenarios:

ScenarioRecommended Setup
Deploying from GitHub in tenant A to Fabric in tenant BOIDC federated identity + app registration in tenant B
External partner accessing Fabric workspace APIsB2B guest user or multi-tenant app registration with appropriate roles
Centralized automation managing multiple tenantsIndividual app registrations per tenant with token exchange

🔗 Microsoft identity platform: Multi-tenant applications

Secret Management with Azure Key Vault​

Store sensitive data like connection strings and API keys in Azure Key Vault and access it via:

  • Fabric Notebooks or Pipelines with linked services
  • Managed identities or app registrations
  • RBAC controls on both the control and data plane

Use separate Key Vaults per environment (dev, test, prod) and enforce least privilege with role assignments.

Recommendations​

  • Prefer managed identities over credentials wherever possible.
  • For GraphQL and REST APIs, use Microsoft Entra App Registrations.
  • Secure CI/CD pipelines with OIDC federation and limit service principal use.
  • Integrate Azure Key Vault for credential storage.
  • Use RBAC and avoid broad roles like Contributor or Owner.
  • For shared resources (e.g., Azure Storage or SQL), define granular permissions at the resource level.

Resources​

Contributors