USERNAME() v/s USERPRINCIPALNAME() in RLS for Power BI Embedded scenarios - When to use what?

[monaraya]

If you are wondering when to use USERNAME() and USERPRINCIPALNAME() in RLS  for Power BI Embedded scenarios, then you are on the right blog.

If you are new to DAX, I would recommend trying these DAX functions in measures or RLS filters.

Reference Documents: USERNAME function (DAX) - DAX | Microsoft Docs

USERPRINCIPALNAME function (DAX) - DAX | Microsoft Docs

On high level, in Power BI Desktop, username() will return domain/username and userprincipalname() function will return username@domain.com.

However, on Power BI Service, both username() and userprincipalname() will return username@domain.com.

Now, let's dig deeper for embedding specific issues.

This article assumes that you have basic knowledge on Power BI Embedded.

You can look at these articles for a refresher.

• Embed content in your Power BI embedded analytics application - Power BI | Microsoft Docs
• Embed content in your Power BI embedded analytics application enabling better embedded BI insights f...
• Using row-level security with embedded content in Power BI embedded analytics - Power BI | Microsoft...

App Owns Data

In case of App Owns Data, the end users' Power BI license or permissions on the embedded artifact (report, dashboard or tile) do not propagate to your web application. In most cases, customers implement their own sign in logic. It is always recommended to use username() function. Here's why.

"username() will respect the basic authentication of your web application/portal and implement RLS as per the signed email address on the web application/portal. Changes made to permissions on Power BI Service does not affect user experience on your web portal.

In simple terms, sign in using abc@def.com on you web application/portal would be different than signing in using abc@def.com on Power BI Service ensuring isolation between the two sign ins."

So you only have to take care that your RLS works as expected on Power BI Desktop.

What will happen if I use userprincipalname() in this scenario? Your embedding will work. However, if you make any changes to permissions on Power BI Service. Those changes will only be propagated if your end user signs into Power BI Service.

E.g.: You make a user X member on the workspace. Since RLS is only respected for Viewer role, end user will see all data on Service as well as your portal. Now, let's say you downgrade user X's permissions to a Viewer on the workspace and add them to the role under Dataset Security.

User X goes to portal without logging into Power BI Service even once. He will still see all data on the portal because he was a member earlier and changes have not propagated yet.

User Owns Data

In case of User Owns Data, the end users need to have Power BI license and required permissions on the embedded artifact (report, dashboard or tile). That is, end users need to sign in to Power BI to view the report in your application too.

In this case, both username() and userprincipalname() functions can be used because you don't have to change anything in the code specifically for RLS secured reports. However, userprincipalname() is recommended so as to avoid any confusions regarding the different behavior on Power BI Desktop and Power BI Service. (USERNAME() will return domain/username on Power BI Desktop and username@domain.com on Power BI Service. I know, bam.)

Conclusion

Even though USERNAME() and USERPRINCIPALNAME() seem similar on the surface, they can act differently in different embedding scenarios. So if you choose the right DAX function, embedding will be fun and easy.

Hope this helps you make the choice. 😊

Author:Akshiita Srivastava

Reviewer:Mounika Narayana Reddy