Microsoft Fabric: semantic models, dynamic row level security, and DirectLake mode
Some of you will be familiar with dynamic row level security (DRLS) in PowerBI. For those that aren't, DRLS allows us to use the email address of the user that is logged into the service via their Entra account. With this email address, and corresponding email address in our semantic model, we can dynamically filter the semantic model to only show the data that user could see.
The result, we can use one report suite to serve the same content to country, region, and global teams whilst simultaneously providing the necessary security around sensitive data. Now back in the world of Power BI, that was really easy. We fired up Power BI desktop, went into manage security roles, and added the necessary DAX:
Why? The challenge is that a number of features break DirectLake connections and force the model back into DirectQuery mode. In fact, for existing Power BI developers, we actually need to change the way we work currently to guarantee that Fabric doesn't drop back into DirectQuery mode. That change is to not use desktop and instead do all your implementation in the service. I know, completely counter intuitive; but trust me, it makes your life easier in the long wrong. I would do this at least until DirectLake mode is fully supported within desktop and using features such as what if parameters doesn't result in DirectLake mode dropping back to DirectQuery mode.
With all these challenges, how do we implement DRLS with DirectLake mode in Microsoft Fabric? Before we begin, we have some general rules to remember:
- You must have a Lakehouse or Warehouse in Fabric containing one or more delta tables.
- Create any static data as physical delta tables within your Lakehouse. You can either do this as a Notebook that's maintained or using DataFlows.
- If you are using a Lakehouse with a medallion architecture, always create your gold layer as delta tables. This will ensure that these tables are added to your SQL endpoint automatically.
- Create yourself a service principle before you start. This will be used to ensure that the semantic model runs as the principle, meaning that it always knows the full context of the model. If we don't do this the model will run as the context of the calling EntraID and we may not be able to see objects we need to apply the DRLS. The rest of the blog assumes that you have the details for this service account before we begin.
- Don't apply any security to the objects in the SQL endpoint. Doing this will cause all PowerBI reports to drop back to DirectQuery mode. This is because the engine has to pass the query back to the SQL endpoint to evaluate the security context and so DirectLake mode can't be used.
Comments
Post a Comment