Forum Discussion

jayasurya_prud's avatar
jayasurya_prud
Icon for Advocate IV rankAdvocate IV
1 month ago
Solved

Understanding Power BI B2B Licensing and Embedded Scenarios

Understanding Power BI B2B Licensing and Embedded Scenarios

I'm trying to understand how Power BI licensing, Microsoft Entra B2B, and Power BI Embedded work together. I'd appreciate clarification on the following scenarios.

Scenario

  • Tenant A owns the Microsoft Entra tenant, Power BI tenant, workspace, semantic model, reports, dashboards, and apps.
  • [email protected] is an external user.

Question 1 – B2B Guest + Pro Workspace

Assume [email protected] is invited as a B2B guest into Tenant A.

The workspace is a Power BI Pro workspace (not Premium Capacity or Fabric Capacity).

  1. What are the exact checks Power BI performs before allowing access?
  2. Are the checks performed in this order?
    • User authentication
    • B2B guest validation
    • Tenant settings
    • Power BI license validation
    • Workspace/App permissions
    • Semantic model permissions
    • RLS
  3. Is this the complete authorization flow, or are there additional checks?

Question 2 – Cross-Tenant Licensing

If the external user has a Power BI Pro license assigned in their home tenant (Tenant B):

  1. Can that license be used to access reports hosted in Tenant A?
  2. If yes, how does Microsoft validate the license across tenants?
  3. Does the guest require a Pro license assigned in Tenant A, or is the home tenant license sufficient?

Question 3 – User Owns Data vs App Owns Data

I'm trying to understand the architectural difference.

User Owns Data

  • Who authenticates to Power BI?
  • Does Power BI evaluate the end user's identity?
  • Is a Pro/PPU license required?
  • What happens if the user has no Power BI license?

App Owns Data

  • Who authenticates to Power BI?
  • Does Power BI evaluate the end user's identity or only the application/service principal?
  • Why is Embedded Capacity required?
  • Why doesn't the end user need a Pro license?

Question 4 – Embedded with Existing B2B Users

Suppose the external user is already a B2B guest in Tenant A.

Instead of accessing reports through Power BI Service, they access them through a secure web application using Power BI Embedded.

  1. Is this a supported architecture?
  2. Should this use User Owns Data or App Owns Data?
  3. Which approach is recommended and why?

Question 5 – Recommended Architecture

For each of the following scenarios, what is the recommended architecture and licensing model?

  • Internal employees
  • External partners (B2B guests)
  • Customers using a secure web portal
  • Public-facing dashboards

When should I choose:

  • Power BI Service
  • B2B Guest Access
  • Power BI Embedded (User Owns Data)
  • Power BI Embedded (App Owns Data)
  • Publish to Web

I'm looking for the recommended architecture along with the licensing requirements for each scenario.



amitchandak 

 

Ashish_Mathur 

super 

 

data protection
dataflow
General Comment
Interesting Links
Need Help
Show and Tell
Tips and Tricks
  • v-kathullac's avatar
    v-kathullac
    1 month ago

    Hi jayasurya_prud 

     

    Thank you for reaching out to Microsoft Fabric Community Forum,Below are the few points which can resolve your issue.Let us know if you need any further assistance.

     

     

    • Tenant B → Power Pages → Power BI Embedded → Tenant A is a supported architecture for external users from different organizations/domains.
    • Use Power BI Embedded – App Owns Data. External users do not need direct Power BI Service access or individual Power BI licenses.
    • For RLS, pass the authenticated user's Effective Identity when generating the embed token.
    • Maintain a security mapping table such as User → Customer → Role → Data Access instead of relying only on email/UPN. This supports future customer groups and role changes.
    • The application should validate the user's identity and authorization server-side before generating the embed token. Do not trust an identity passed directly from the browser.
    • Use a stable user/customer identifier for RLS mapping, especially because users may have Gmail, guest, or different organizational identities.
    • For this scenario, Embed Token + Power BI JavaScript embedding is recommended over Secure Embed/iframe because it provides better control over authentication, dynamic RLS, and authorization.
    • When permissions change, ensure the application uses the latest authorization mapping when generating/renewing the embed token to prevent stale access.
    • Before finalizing, test Effective Identity, RLS mappings, multiple roles/groups, token expiration/renewal, and user access revocation.

    Thanks,

    Chaithanya.

     

9 Replies

  • v-kathullac's avatar
    v-kathullac
    Icon for Community Support rankCommunity Support
    1 month ago

    Hi jayasurya_prud ,

     

    Thank you for reaching out to Microsoft Fabric Community Forum,Below are the few points which can resolve your issue.Let us know if you need any further assistance.

     

    • B2B Guest + Pro Workspace: The external user must be added as a Microsoft Entra B2B guest, have access to the Power BI workspace/app/report, and have the required Power BI license for the capacity where the content is hosted.
    • Cross-Tenant Licensing: A B2B guest's Power BI Pro/PPU license from their home tenant can generally be used for accessing Power BI content shared from the provider tenant. A separate Pro license in Tenant A is not automatically required.
    • Permissions vs Licensing: B2B guest status only establishes the user's external identity. It does not automatically grant Power BI access. The user still needs the correct Power BI permissions.
    • RLS: After the user is authorized to access the semantic model, RLS controls which data the user can see. Ensure the RLS role correctly recognizes the B2B guest identity.
    • User Owns Data: Use this when users are Power BI users and need direct or secure embedded access based on their own Power BI identity and license. Best suited for employees and B2B partners who already use Power BI.
    • App Owns Data: Use this when customers or external users access reports through your own secure application. The application authenticates to Power BI using a service principal, so end users generally do not need individual Power BI licenses.
    • Embedded Capacity: App Owns Data requires appropriate Power BI Embedded/Fabric capacity for production workloads because the application, rather than each individual viewer, is consuming the Power BI content.
    • Existing B2B + Embedded: If the external user already exists as a B2B guest but only needs to view reports through your web application, you normally do not need to use their B2B identity for the embedded experience. App Owns Data is generally cleaner.
    • Do not use Publish to Web for confidential, customer-specific, or sensitive data because it is publicly accessible and should not be treated as a secure RLS solution.

    Thanks,

    Chaithanya.

     

    • jayasurya_prud's avatar
      jayasurya_prud
      Icon for Advocate IV rankAdvocate IV
      1 month ago

      Hi  , thank you for the clarification. I have one follow-up architecture question.

      Consider the following scenario:

       

      • Tenant A hosts all Microsoft Fabric resources, including the Fabric capacity, Power BI workspaces, semantic models, reports, and apps.
      • Tenant B is a separate Microsoft Entra tenant used only for managing external customer identities. The organization intentionally wants to keep external users out of Tenant A to avoid cluttering the production directory.
      • External users only need to view reports through a secure customer portal. They do not need direct access to Power BI Service (app.powerbi.com).

      Based on my understanding, would the following architecture be the recommended approach?

      1. External users authenticate against Tenant B.
      2. The custom portal validates and authorizes the user.
      3. The portal uses a Service Principal from Tenant A to authenticate with Power BI.
      4. The portal generates an Embed Token (passing Effective Identity if RLS is required).
      5. The report from Tenant A is embedded into the portal using App Owns Data.

      In this architecture:

      • External users never access Power BI Service directly.
      • External users do not need to exist as B2B guests in Tenant A.
      • External users do not require individual Power BI Pro licenses.
      • The application is responsible for authentication and authorization, while Power BI enforces RLS using the Effective Identity.

      Is this understanding correct, or is there any Microsoft-recommended approach for keeping external identities in a separate Entra tenant while consuming reports hosted in another tenant?

  • v-kathullac's avatar
    v-kathullac
    Icon for Community Support rankCommunity Support
    1 month ago

    Hi jayasurya_prud ,

     

    Thank you for reaching out to Microsoft Fabric Community Forum,Below are the few points which can resolve your issue.Let us know if you need any further assistance.

     

     

    • Yes, your proposed architecture is the Microsoft-recommended approach for customer-facing embedding scenarios using App Owns Data (Power BI Embedded). External users authenticate with Tenant B, while the custom application handles authentication and authorization.
    • The application uses a Service Principal in Tenant A to access Power BI resources and generate Embed Tokens.
    • If Row-Level Security (RLS) is required, pass the Effective Identity when generating the embed token so Power BI enforces data security.
    • External users do not need to be added as B2B guest users in Tenant A because they never access the Power BI Service directly.
    • External users do not require individual Power BI Pro licenses. Instead, the embedding application requires appropriate Power BI Embedded/Fabric capacity licensing.
    • The Power BI content (workspace, semantic model, and reports) remains securely hosted in Tenant A, while Tenant B is used solely for identity management.
    • This architecture cleanly separates identity management (Tenant B) from analytics hosting (Tenant A), making it suitable for external customer portals while keeping the production tenant free of guest accounts.
    • Ensure the Service Principal is granted access only to the required workspace and follows the principle of least privilege.

    Thanks,

    Chaithanya.

     

    • jayasurya_prud's avatar
      jayasurya_prud
      Icon for Advocate IV rankAdvocate IV
      1 month ago

      Thank you for the clarification. Your explanation was very helpful.

      I have one follow-up scenario that I'd like to validate.

      Suppose an organization has two separate Microsoft Entra tenants:

      Tenant A

      • Hosts all Microsoft Fabric resources
      • Fabric Capacity
      • Power BI Workspaces
      • Semantic Models
      • Reports
      • Service Principal

      Tenant B

      • Used only for managing external users and identities
      • No Fabric or Power BI resources are hosted here

      Now, the external users themselves belong to different organizations and different Microsoft Entra tenants. For example:

      • User A → Company X Tenant
      • User B → Company Y Tenant
      • User C → Company Z Tenant

      These users are managed/authenticated through Tenant B, and the business requirement is that they only need to consume Power BI reports through a custom web portal. They do not need direct access to Power BI Service (app.powerbi.com).

      Based on my understanding, would the following architecture still be the recommended approach?

      1. External users authenticate through Tenant B (which manages external identities).
      2. The custom portal authenticates and authorizes the users.
      3. The portal uses a Service Principal in Tenant A to access Power BI.
      4. The portal generates an Embed Token (passing Effective Identity if RLS is required).
      5. Reports hosted in Tenant A are embedded into the portal using App Owns Data.

      In this scenario:

      • The external users originate from completely different Microsoft Entra tenants.
      • They are not created as B2B guest users in Tenant A.
      • Tenant A only hosts the analytics platform.
      • Tenant B only manages external identities.

      Is this architecture still fully supported and recommended by Microsoft, or would there be any additional considerations when the external users originate from multiple different Entra tenants?

  • v-kathullac's avatar
    v-kathullac
    Icon for Community Support rankCommunity Support
    1 month ago

    Hi jayasurya_prud  ,

     

    As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided for the issue worked? or Let us know if you need any further assistance?

     

    Regards,

    Chaithanya

  • v-kathullac's avatar
    v-kathullac
    Icon for Community Support rankCommunity Support
    1 month ago

    Hi jayasurya_prud ,

     

    • Yes, this architecture is supported and recommended for the Power BI Embedded  App Owns Data scenario.

    • Users from different Entra tenants do not need to be added as B2B guests in Tenant A.

    • Tenant A can host all Fabric/Power BI resources and the Service Principal.

    • Tenant B can handle external user authentication and identity management.

    • The custom portal handles authentication, authorization, and customer/tenant mapping.

    • The Tenant A Service Principal generates the Power BI Embed Token.

    • If RLS is required, pass the appropriate Effective Identity/RLS role when generating the embed token.

    • External users do not need direct Power BI Service access or individual Power BI licenses for this embedded scenario.

    • The main consideration is to ensure the portal/backend securely controls which customer/tenant data each user can access Therefore, users coming from multiple external Entra tenants do not change the overall architecture.

    Thanks,

    Chaithanya.

  • v-kathullac's avatar
    v-kathullac
    Icon for Community Support rankCommunity Support
    1 month ago

    Hi @jayasurya_prud  ,

     

    As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided for the issue worked? or Let us know if you need any further assistance?

     

    Regards,

    Chaithanya

    • jayasurya_prud's avatar
      jayasurya_prud
      Icon for Advocate IV rankAdvocate IV
      1 month ago

      Thank you for the clarification. This is the last scenario we would like to validate before we finalize the architecture.

      Scenario

      We have two separate Microsoft Entra tenants:

      Tenant A – Analytics / Power BI Tenant

      • Microsoft Fabric Capacity

      • Power BI Workspaces

      • Semantic Models

      • Power BI Reports

      • All Power BI/Fabric content is hosted here

      Tenant B – External User Identity Tenant

      • External users are managed/authenticated here.

      • The external users can belong to completely different organizations and domains, including identities such as Gmail accounts.

      • These users are provided access to a Power Pages application.

      • They only need to consume/interact with the Power BI reports through the Power Pages portal.

      • They do not require direct access to Power BI Service.

      The intended flow is:

      External User → Tenant B Authentication → Power Pages → Power BI Embedded → Report hosted in Tenant A

      We are considering App Owns Data / Embed for your customers for this scenario, with Tenant A remaining completely separate from the external user identities in Tenant B.

      RLS Requirement

      We also need Row-Level Security (RLS).

      The Power Pages application will know the authenticated user's identity and authorization context, and the Power BI report/semantic model should restrict the data accordingly.

      The authorization model may evolve over time, so we want to ensure the RLS design can support future scenarios such as additional customer groups, roles, or other levels between the authenticated user and the data.

      Could you please confirm:

      1. Is Tenant B → Power Pages → App Owns Data → Power BI content in Tenant A fully supported for external users from different organizations/domains?

      2. Can the authenticated Power Pages user be passed as the Effective Identity when generating the embed token so that Power BI RLS can be applied?

      3. Are there any RLS edge cases or corner cases we should consider with this multi-tenant setup, particularly around external identities, identity formats/UPNs, multiple authorization mappings, role/group hierarchy, or changes to user access?

      4. Are there any limitations around dynamically passing the user identity/security context from Power Pages to Power BI for RLS?

      5. If the security mapping changes, what is the recommended approach to ensure the updated access is reflected without creating security gaps?

      Embedding Approach

      For the Power Pages implementation, we would also like to confirm the recommended embedding mechanism.

      Should we use:

      • Power BI Embed Token + Power BI JavaScript/API-based embedding, or

      • Power BI report URL / iframe-based embedding (Secure Embed)?

      Given that the users are external customers, do not require direct Power BI Service access, and RLS needs to be enforced dynamically, which approach would Microsoft recommend for this scenario?

      Finally, are there any other edge cases, limitations, or corner cases we should account for before finalizing the architecture?

      Thank you again for your guidance. This will help us finalize the solution design.

  • v-kathullac's avatar
    v-kathullac
    Icon for Community Support rankCommunity Support
    1 month ago

    Hi jayasurya_prud 

     

    Thank you for reaching out to Microsoft Fabric Community Forum,Below are the few points which can resolve your issue.Let us know if you need any further assistance.

     

     

    • Tenant B → Power Pages → Power BI Embedded → Tenant A is a supported architecture for external users from different organizations/domains.
    • Use Power BI Embedded – App Owns Data. External users do not need direct Power BI Service access or individual Power BI licenses.
    • For RLS, pass the authenticated user's Effective Identity when generating the embed token.
    • Maintain a security mapping table such as User → Customer → Role → Data Access instead of relying only on email/UPN. This supports future customer groups and role changes.
    • The application should validate the user's identity and authorization server-side before generating the embed token. Do not trust an identity passed directly from the browser.
    • Use a stable user/customer identifier for RLS mapping, especially because users may have Gmail, guest, or different organizational identities.
    • For this scenario, Embed Token + Power BI JavaScript embedding is recommended over Secure Embed/iframe because it provides better control over authentication, dynamic RLS, and authorization.
    • When permissions change, ensure the application uses the latest authorization mapping when generating/renewing the embed token to prevent stale access.
    • Before finalizing, test Effective Identity, RLS mappings, multiple roles/groups, token expiration/renewal, and user access revocation.

    Thanks,

    Chaithanya.