Azure Databricks Multi Tenant Solution

[funsjanssen]

Hello Everyone,

For the past few months, we’ve been extensively exploring the use of Databricks as the core of our data warehousing product. We provide analytics dashboards to other organizations and are particularly interested in the Column-Level Security (CLS) and Row-Level Security (RLS) options, as data needs to be scoped per user, role, or organization.

We need to ensure that our customers (organizations with different identity providers, primarily Entra) can query their data using Single Sign-On (SSO) with Power BI or our custom embedded analytics app. While Entra B2B collaboration seems to support this, it requires an Entra Premium license for Multi-Factor Authentication (MFA) trust options. This is quite costly for our user base of over 20,000, exceeding even the cost of Databricks itself.

On Databricks AWS, it appears possible to use OIDC or SAML directly as SSO providers. However, we haven’t found this option in Azure Databricks. We’re considering using a solution like Auth0 to connect all our customers.

Has anyone implemented a similar setup using Azure Databricks? Any insights or experiences would be greatly appreciated.

Thank you!

[Namanak47]

Could you please let me know or provide a link how is it done in Databricks AWS using OIDC or SAML directly as SSO providers.
I have exactly same kind of use case

[mark_ott]

Implementing robust Row-Level Security (RLS) and Column-Level Security (CLS) in Azure Databricks for multi-tenant analytics—especially with seamless SSO from Power BI and custom apps—is a common concern for B2B SaaS providers scaling to large user bases. Here's a summary of current best practices, limitations, and peer insights relevant to your scenario:

SSO Options for Azure Databricks

• Azure Databricks primarily integrates with Azure Entra ID (formerly Azure AD) for authentication and SSO. Unlike the AWS Databricks environment, which more flexibly supports direct custom OIDC or SAML providers, Azure Databricks authentication flows rely on being part of the Azure identity ecosystem.

• OIDC/SAML support: As of late 2025, Azure Databricks does not natively support directly configuring external OIDC/SAML providers (like Auth0) for workspace authentication. This is a key difference from Databricks on AWS and GCP, which allow broader federation.

Power BI Integration and Multi-Tenancy

• Power BI → Azure Databricks: SSO for user-level identity propagation from Power BI to Databricks requires using Azure Entra ID for both Power BI and Databricks. This means that end-users typically need to be registered in your tenant (or as Entra B2B guests).

• B2B & MFA Licensing: Entra B2B collaboration allows you to federate external identities, but applying MFA trust (to avoid forcing all external users to re-authenticate or buy Premium P1/P2 licenses) is expensive at scale, as you discovered.

Security (RLS/CLS) Implementation

• Dynamic Views: RLS in Databricks is typically managed via dynamic views in Unity Catalog, where SQL code references the current_user() or similar context variables. These models are well-supported, but they rely on trusted identity propagation—tying back to your SSO setup.

• Column-level masking: Unity Catalog allows fine-grained column-level security via masking policies. These can reference user/role attributes if those are consistently and securely federated in the session context.

Community & Peer Recommendations

• No direct third-party IDP: Most organizations working around the lack of direct Auth0/OIDC integration in Azure Databricks achieve SSO either by:

  • Requiring users (and their organizations) to exist as Entra guests, sometimes scripted or automated for large-scale onboarding.

  • Using Entra B2B but absorbing the cost for Premium P1/P2 only for users who require MFA trust, or segmenting high-value customer orgs.

• Custom Application Middle-Tier: Some teams implement a brokered login flow, where their custom analytics app authenticates with Auth0 (or equivalent), then uses a service principal (in Entra) to proxy or impersonate users for Databricks access—though this reduces true end-user context in Databricks and complicates fine-grained RLS/CLS. This model often falls short for precise, auditable user-level traceability.

Specific Workarounds and Community Feedback

• Direct OIDC via Auth0 for Azure Databricks is not natively available; all identity flows revert to requiring Entra.

• B2B with Entra is feasible and robust, but as mentioned, it is cost-prohibitive with strict MFA trust policies at your scale.

• Some companies opt for federating their customer identities into Entra using automated scripts/APIs for onboarding, and then setting per-org/tenant RBAC in the Unity Catalog layer.

• For embedded analytics, if you control the authentication flow in your custom app, you may build a brokered token service: your app translates Auth0 tokens to Entra tokens (using a confidential client/service principal) for Databricks SQL endpoints, but this introduces risk and may reduce auditing fidelity.

---

Key Takeaways

• As of late 2025, direct Auth0/OIDC federation for end-user SSO to Azure Databricks is not supported; identity routing must transit through Entra.

• B2B with Entra is robust but expensive for MFA trust at mass scale; most organizations live with this cost or segment only sensitive users for Premium licenses.

• Dynamic RLS/CLS in Unity Catalog relies on accurate user context—which in turn depends on true user federation into your Entra tenant.

• For massive scale with many external enterprise users, automating Entra guest onboarding is the most common (if not ideal) workaround. Direct Auth0 as an "SSO bridge" is not currently feasible for Azure Databricks without major caveats.

If you are seeking an immediate workaround for scaling B2B SSO affordably, consider lobbying your Microsoft account team for roadmap updates or looking at a hybrid Entra onboarding/app-layer impersonation model, with clear documentation of the trade-offs for security and audit.