Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
For new multitenancy solutions, use dedicated Microsoft Entra service principals for customer identities. Where the hosting and trust requirements fit your solution, use managed identity and federated identity credentials to authenticate those customer applications without storing their client secrets or certificate private keys.
Service principal profiles remain a valid, optional solution for new and existing Power BI Embedded applications whose requirements fit their advantages and limitations. They're not deprecated. If your existing profile-based solution meets your requirements, you can continue using it.
This article helps you choose an identity model and find the appropriate configuration guidance. A customer is a logical customer or authorization boundary in your application, not necessarily a separate Microsoft Entra tenant.
Recommended model: Dedicated customer service principals
Create an application registration and service principal for each customer authorization boundary. Grant that principal access only to the customer's permitted workspaces and resources. Dedicated principals provide independent Microsoft Entra sign-in records, directory administration, and access to services that support those identities.
Where eligible and licensed, you can apply workload identity Conditional Access directly to customer service principals. Creating a principal doesn't automatically grant access or enable an unsupported API operation. Check the identity support and permission requirements of each target service.
Choose an authentication method
The recommended authentication pattern uses a user-assigned managed identity on the application's supported Azure compute resource as an assertion source. A federated identity credential on each customer application registration trusts that managed identity. At runtime, the application exchanges the managed identity assertion for a resource access token representing the selected customer service principal.
This pattern removes the need to store and rotate customer application secrets or certificates. It doesn't eliminate application registration, trust administration, resource permissions, or customer identity lifecycle management.
The managed identity and the application registrations that trust it must belong to the same Microsoft Entra directory tenant. Target resources in another tenant have additional application configuration, consent, and permission requirements. Cross-cloud token exchange isn't supported. See the pattern and trust requirements.
If you don't want to use managed identity and federation, authenticate the dedicated customer applications directly with certificates or another supported application credential. Protect stored credentials and automate rotation. See the direct-authentication alternative.
Plan authorization and scale
Neither dedicated principals nor profiles automatically create cryptographic customer isolation. A shared runtime managed identity can authenticate as every customer application that trusts it. Likewise, a runtime with access to multiple stored customer credentials can use those identities. Protect the runtime and resolve the customer's identity and allowed resources through trusted server-side configuration.
Workspace and resource permissions enforce access. Configure required tenant settings and grant each customer principal the least-privileged supported resource roles. For group-scoped settings, explicitly include every relevant principal in an allowed security group.
Dedicated identities consume Microsoft Entra directory objects. Compare your customer count with directory quotas, provisioning permissions and throughput, and each service's resource limits. Automate onboarding, monitoring, and offboarding. Don't select an identity model solely from the number of application users.
Alternative model: Service principal profiles
Profiles provide lightweight customer contexts under a parent service principal. You can create profiles without a separate Microsoft Entra application registration for every customer. A parent can create up to 100,000 profiles, and each profile can access or create up to 1,000 workspaces within the documented limits.
Profiles can fit applications that value this scaling and administration model and don't require independent Entra identities for their customer contexts. They support the documented Power BI REST API, .NET SDK, and XMLA/TOM interfaces, but not Fabric REST APIs. Profiles also lack independent Entra sign-in records and per-profile workload identity Conditional Access, and remain bound to their parent.
A managed identity parent can authenticate without stored application secrets, but doesn't turn its profiles into independent Entra identities or expand their API support.
Evaluate the advantages and limitations of the optional profile solution before choosing it. Separate customer workspaces and semantic models can support either identity model; those data-design benefits aren't exclusive to profiles.
Find the appropriate implementation guidance
Use the guidance that matches your chosen model and current solution:
| Situation | Start here |
|---|---|
| Build a new solution with dedicated customer principals | Implementation guide. The profile inventory and decommissioning phases don't apply to a new application. |
| Choose profiles for a new or existing application | Service principal profiles: An optional multitenancy solution, followed by detailed profile configuration. |
| Use the profile model through the SDK | Power BI SDK and service principal profiles. |
| Existing profiles meet your requirements | Continue using them and maintain the required customer routing, permissions, and lifecycle controls. |
| Existing profiles constrain your requirements | Replace service principal profiles with service principals. |