Best practices for implementing row level security using effective identity

[sri_palagummi]

Hi all -

We are planning to implement row level security for our reports. The reports will be embedded in a portal that will be visible externally to our customers. Customers log in to the portal to access the reports. However, we are not implementing security at the database level. Instead, we are planning to use effective identity and use that to restrict data. This effective identity will be generated along with the access token so that it is always unique per customer per session.

I would like to know if anyone else have used this approach and if so, the best practices to implement this. What are the best ways to test this solution and ensure security works as designed. We are also worried about the possibility of accidentally pushing reports without RLS enforced (that would expose the entire dataset to all customers). Are there any tools in Power BI that automatically checks for this? Thanks!!!

[v-tejrama]

Hi @sri_palagummi ,

Using effective identity to implement row-level security in Power BI embedded reports is a solid approach when you are not enforcing security at the database level. The idea is to pass each customer's identity through the access token when they log in to your portal, so Power BI knows exactly which data to show for that user. To make this work effectively, define your RLS roles in Power BI Desktop using a column that identifies the customer, like a customer ID or email, and test these roles thoroughly before publishing. You can use the View as Role feature in Desktop to simulate different users and verify that only the correct data is visible. Once you publish, make sure your embedding solution generates a unique effective identity for every customer session and includes the appropriate roles. It is also a good practice to have a default restricted role that applies to any unidentified or misconfigured users so that no data is accidentally exposed.

Testing with real or simulated accounts is crucial to ensure everything works as intended, and you can also use scripts with the Power BI REST API to automate validation if you want additional safety. While Power BI does not have a built-in tool to automatically detect datasets without RLS, using deployment pipelines and careful review before publishing can help prevent mistakes. Additionally, monitor access with activity logs and make sure your access tokens expire appropriately to maintain security. Following this approach will help you deliver a secure, reliable experience for your customers while keeping the data properly restricted.

For reference, Microsoft has useful documentation on embedding reports with RLS, generating embed tokens, and managing deployment pipelines that can guide you through the process in detail.

Thank you,

Tejaswi.

[v-tejrama]

Hi @sri_palagummi ,

I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.

Thank you.

[v-tejrama]

Hi @sri_palagummi ,

I wanted to follow up and see if you had a chance to review the information shared. If you have any further questions or need additional assistance, feel free to reach out.

Thank you.

[sri_palagummi]

Apologies for the delay. I was on vacation last week. Please go ahead and close this thread. I have the information I need.

[grazitti_sapna · Accepted solution]

Hi @sri_palagummi, 

We’ve implemented row-level security (RLS) using effective identity for our embedded reports too. Basically, instead of managing roles directly in the database, we pass the user’s identity (like email or customer ID) through the access token when they log in to our portal. This way, Power BI knows exactly which data each user should see.

A few best practices we follow:

• Always make sure the RLS roles are defined and tested in Power BI Desktop before publishing.

• Use test accounts to verify that each customer only sees their own data.

• Keep a “default or restricted” view for any unidentified users, so even if something breaks, no data is overexposed.
  
  

🌟 I hope this solution helps you unlock your Power BI potential! If you found it helpful, click 'Mark as Solution' to guide others toward the answers they need.

💡 Love the effort? Drop the kudos! Your appreciation fuels community spirit and innovation.

🎖 As a proud SuperUser and Microsoft Partner, we’re here to empower your data journey and the Power BI Community at large.

🔗 Curious to explore more? [Discover here].

Let’s keep building smarter solutions together!