Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Get Fabric Certified for FREE during Fabric Data Days. Don't miss your chance! Request now

Reply
csette1329
New Member

Power BI embedded reports with RLS

I'm making a report that contains RLS rules based on the function USERPRINCIPALNAME(). Basically, I've created a measure that will:

- get logged in user's email
- do a VALUELOOKUP and find their user_id
- check in a table what permissions that user_id has
- hide or show values based on permissions


The measures are working as expected. Now my client wants to embed this report in a website (outside Microsoft's domain).

I would like to know what changes do I need to make in the logic of the measures? How does the embedded report authenticates the user viewing that page? Can I still use USERPRINCIPALNAME() in the embedded report?

2 ACCEPTED SOLUTIONS
tayloramy
Community Champion
Community Champion

Hi @csette1329

 

How do you plan on embedding the report? 
RLS at the semantic model level like this only works with authenciated users. 

 

If you embed “for your organization” (user-owns-data): viewers sign in with Microsoft Entra ID. USERPRINCIPALNAME() keeps working as-is because Power BI passes the signed-in user through. No DAX changes needed. See: Embed a report with RLS.

 

If you embed “for your customers” (app-owns-data): your app authenticates users, not Power BI. USERPRINCIPALNAME() won’t automatically be the website viewer; you must pass an effective identity (username/roles) when you call GenerateToken. In DAX you can still use USERPRINCIPALNAME() (it will return the username you supply), or use CUSTOMDATA() if you prefer passing an immutable user_id. Docs: Generate embed token, RLS with embedding, CUSTOMDATA(), USERPRINCIPALNAME().

 

If you're making a public web report, RLS will not function. See this post for more details: Solved: USERPRINCIPALNAME() in Public Web Reports - Microsoft Fabric Community

 

If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, please mark this as the solution.

View solution in original post

Poojara_D12
Super User
Super User

Hi @csette1329 

When you embed a Power BI report that uses Row-Level Security (RLS) based on USERPRINCIPALNAME(), the behavior of that function depends entirely on the embedding method and authentication flow. In the Power BI Service, USERPRINCIPALNAME() automatically returns the signed-in user's email address (from Azure AD), which works perfectly for internal users within your organization. However, when the same report is embedded in an external website (outside Microsoft’s domain), there’s no direct sign-in context unless you explicitly pass one through your embedding setup.

 

If you are embedding the report using Power BI Embedded (service principal with embed tokens), USERPRINCIPALNAME() will not return the viewer’s identity; instead, it will reflect the identity under which the embed token was generated (usually a service principal or master account). To maintain RLS in such scenarios, you must implement “Effective User” or “Row-Level Security via Embed Tokens” — meaning your web application must authenticate the external user first (via your app’s own authentication system) and then generate a Power BI embed token with the user’s identity or role assigned. Power BI will enforce RLS based on that token rather than the logged-in Azure AD account.

 

In short, your DAX logic using USERPRINCIPALNAME() will continue to work if your embed implementation correctly passes the user identity through the embed token; otherwise, it will always show data for the token generator (not the viewer). So, you don’t need to change your DAX measures, but you do need to ensure your embedding solution supports per-user embedding with RLS-aware tokens — not generic app-level embedding — to preserve secure, user-specific filtering.

 

Did I answer your question? Mark my post as a solution, this will help others!
If my response(s) assisted you in any way, don't forget to drop me a "Kudos"

Kind Regards,
Poojara - Proud to be a Super User
Data Analyst | MSBI Developer | Power BI Consultant
Consider Subscribing my YouTube for Beginners/Advance Concepts: https://youtube.com/@biconcepts?si=04iw9SYI2HN80HKS

View solution in original post

4 REPLIES 4
Poojara_D12
Super User
Super User

Hi @csette1329 

When you embed a Power BI report that uses Row-Level Security (RLS) based on USERPRINCIPALNAME(), the behavior of that function depends entirely on the embedding method and authentication flow. In the Power BI Service, USERPRINCIPALNAME() automatically returns the signed-in user's email address (from Azure AD), which works perfectly for internal users within your organization. However, when the same report is embedded in an external website (outside Microsoft’s domain), there’s no direct sign-in context unless you explicitly pass one through your embedding setup.

 

If you are embedding the report using Power BI Embedded (service principal with embed tokens), USERPRINCIPALNAME() will not return the viewer’s identity; instead, it will reflect the identity under which the embed token was generated (usually a service principal or master account). To maintain RLS in such scenarios, you must implement “Effective User” or “Row-Level Security via Embed Tokens” — meaning your web application must authenticate the external user first (via your app’s own authentication system) and then generate a Power BI embed token with the user’s identity or role assigned. Power BI will enforce RLS based on that token rather than the logged-in Azure AD account.

 

In short, your DAX logic using USERPRINCIPALNAME() will continue to work if your embed implementation correctly passes the user identity through the embed token; otherwise, it will always show data for the token generator (not the viewer). So, you don’t need to change your DAX measures, but you do need to ensure your embedding solution supports per-user embedding with RLS-aware tokens — not generic app-level embedding — to preserve secure, user-specific filtering.

 

Did I answer your question? Mark my post as a solution, this will help others!
If my response(s) assisted you in any way, don't forget to drop me a "Kudos"

Kind Regards,
Poojara - Proud to be a Super User
Data Analyst | MSBI Developer | Power BI Consultant
Consider Subscribing my YouTube for Beginners/Advance Concepts: https://youtube.com/@biconcepts?si=04iw9SYI2HN80HKS
v-ssriganesh
Community Support
Community Support

Hi @csette1329,

Thank you for posting your query in the Microsoft Fabric Community Forum, and thanks to @tayloramy for sharing valuable insights.

 

Could you please confirm if your query has been resolved by the provided solutions? This would be helpful for other members who may encounter similar issues.

 

Thank you for being part of the Microsoft Fabric Community.

tayloramy
Community Champion
Community Champion

Hi @csette1329

 

How do you plan on embedding the report? 
RLS at the semantic model level like this only works with authenciated users. 

 

If you embed “for your organization” (user-owns-data): viewers sign in with Microsoft Entra ID. USERPRINCIPALNAME() keeps working as-is because Power BI passes the signed-in user through. No DAX changes needed. See: Embed a report with RLS.

 

If you embed “for your customers” (app-owns-data): your app authenticates users, not Power BI. USERPRINCIPALNAME() won’t automatically be the website viewer; you must pass an effective identity (username/roles) when you call GenerateToken. In DAX you can still use USERPRINCIPALNAME() (it will return the username you supply), or use CUSTOMDATA() if you prefer passing an immutable user_id. Docs: Generate embed token, RLS with embedding, CUSTOMDATA(), USERPRINCIPALNAME().

 

If you're making a public web report, RLS will not function. See this post for more details: Solved: USERPRINCIPALNAME() in Public Web Reports - Microsoft Fabric Community

 

If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, please mark this as the solution.

Hi @tayloramy 

Thanks for your reply!

That was really helpful. I plan on embedding using the "for your customers" solution. I'll see if the embed token contains an useful user_id that I can use with CUSTOM DATA() function in DAX.

Helpful resources

Announcements
Fabric Data Days Carousel

Fabric Data Days

Advance your Data & AI career with 50 days of live learning, contests, hands-on challenges, study groups & certifications and more!

October Power BI Update Carousel

Power BI Monthly Update - October 2025

Check out the October 2025 Power BI update to learn about new features.

FabCon Atlanta 2026 carousel

FabCon Atlanta 2026

Join us at FabCon Atlanta, March 16-20, for the ultimate Fabric, Power BI, AI and SQL community-led event. Save $200 with code FABCOMM.

Top Kudoed Authors