Fixed Identity and RLS in Microsoft Fabric Direct Lake Semantic Model : Perfect Pair 💏

---

When dealing with massive amounts of data stored in modern platforms like Microsoft Fabric, one challenge always looms: How do you secure access while making the process seamless for users?

Fixed Identity and Row-Level Security (RLS)—a duo that not only simplifies access management but also ensures everyone gets exactly the data they’re supposed to see.

Let’s unpack what Fixed Identity is all about, how it works, and why pairing it with RLS is a game-changer for Microsoft Fabric’s Direct Lake architecture.

---

What is Fixed Identity?

Think of Fixed Identity as a system-managed backstage pass. It’s like a service account that quietly handles data access behind the scenes, so your users don’t need to worry about whether they have the right permissions to the underlying data source. Here’s why it’s brilliant:

• Centralized and Consistent: It’s managed by the system and stays the same for all users, ensuring a stable connection.

• Not User-Specific: Unlike traditional connections tied to individual user accounts, this is independent of who’s accessing the data.

• Reliable Access Point: Provides secure and seamless access to datasets stored in Lakehouse or Warehouse.

In short, Fixed Identity is all about simplifying data access while keeping it secure.

---

How Does It Work?

Let’s walk through how Fixed Identity fits into the Direct Lake setup and works its magic:

1. Assigned Permissions: Fixed Identity is granted permission to access the Lakehouse or Warehouse.

2. User Requests Data: When someone opens a Power BI report, their identity is validated, but they don’t connect directly to the data source.

3. Data Retrieval via Fixed Identity: The semantic model in the dataset uses the Fixed Identity to fetch data. The user’s personal credentials are not used here.

4. RLS Rules Kick-In: Row-Level Security (RLS) dynamically filters the data based on the user’s role or permissions.

5. Display in Power BI: Only the filtered data that the user is allowed to see is displayed in the report.

And just like that, users get the data they need without ever having direct access to the underlying storage.

---

Why Pair Fixed Identity with RLS?

Let’s be honest: giving users direct access to storage can be messy. It’s a potential security risk, especially when dealing with sensitive data. That’s where Fixed Identity shines. When you combine it with RLS, here’s what happens:

• Middleman Access: Fixed Identity acts as the middleman, fetching data on behalf of users. RLS then filters that data, ensuring users see only what they’re supposed to.

• No Direct Storage Access: Users don’t need permissions to access the Lakehouse or Warehouse directly—everything is managed via the dataset.

• Controlled Visibility: RLS rules personalize the data experience for users based on their roles.

It’s the perfect setup for scenarios where data access needs to be restricted, but reports still need to flow smoothly.

---

Step-by-Step Breakdown of the Workflow

Let’s use the diagram to explain how everything fits together:

1. User Access Report: A user opens a Power BI report.

2. Power BI Validates User: The Power BI Service checks who the user is and requests data from the semantic model.

3. Semantic Model Applies RLS: RLS rules defined in the semantic model are applied to filter the data.

4. Fixed Identity Steps In: The semantic model uses Fixed Identity to query the data from the Lakehouse or Warehouse.

5. Data Lake Interaction: Fixed Identity retrieves raw data from the Lakehouse or Warehouse using Direct Lake.

6. Filtered Data Returned: The raw data is filtered via RLS and sent back to Power BI.

7. User See the Report: The report is displayed with only the data the user is authorized to view.

This workflow ensures security, simplicity, and a seamless user experience.

---

What Happens Without Fixed Identity?

Without Fixed Identity, things get complicated:

• User-Specific Access: Power BI relies on the user’s credentials to access data.

• Restricted Access: Users without direct permissions for the Lakehouse/Warehouse can’t see the report, even if RLS is correctly configured.

• More Complexity: Permissions need to be managed at both the storage and dataset levels, which exposes the entire dataset.

Basically, Fixed Identity saves the day by simplifying all of this.

---

Benefits of Fixed Identity and RLS

Why should you care about this setup? Here’s why:

• Simplified Permission Management: No need to manage individual user access to storage. Everything is centralized in the dataset.

• Enhanced Security: Users only see what they’re supposed to, thanks to RLS.

• Flexibility: You can securely share reports with users who don’t have direct storage access.

• Streamlined Governance: With RLS and Fixed Identity, all security rules are managed in one place.

---

Tips

Use a Fixed Identity - This is Important! When your semantic model connects to the Lakehouse, don't let it use each viewer's login (single sign-on). Instead, set up one trusted connection (Fixed Identity) to handle all data access. This is like having one security guard checking IDs instead of letting everyone use their key.

When implementing Row-Level Security (RLS) with Direct Lake semantic models, using a fixed identity is crucial. 💡

By default, the connection between your Direct Lake semantic model and the Lakehouse operates on a single sign-on, meaning users access Lakehouse delta table data with their credentials. However, this default behavior should be modified to use a fixed identity instead.

Fixed identity means the model owner explicitly configures their credentials in the semantic model settings, which will then be used universally regardless of who views the report. This doesn't compromise security – the RLS in the semantic model still identifies individual users and applies the appropriate security rules based on who's viewing the report. The key difference is that the model uses fixed identity credentials to access the Lakehouse table data when displaying report visuals. 🔐

Security implementation varies significantly based on how you grant access. When users receive "Viewer" permission to the workspace (which isn't recommended for sensitive data), they gain unrestricted access to all Lakehouse data through direct clicks. The semantic model's RLS only restricts data access when users view reports through that specific model. This relationship becomes evident in the workspace lineage view through directional arrows. ▶️

The recommended approach for securing data is to publish the report as an App and then grant users "Viewer" permission at the App level. This method prevents direct Lakehouse access entirely. Users rely on the fixed identity (belonging to someone with Lakehouse data access) to view any data through the semantic model. This setup mirrors traditional database security patterns. 📊

Consider a scenario where User 1 has SQL database access and creates a semantic model, publishing it with their credentials for Power BI service access. When User 1 shares reports built from this model with User 2 (who lacks direct database access), User 2 only sees data as defined by the semantic model's RLS rules. Direct Lake scenarios introduce a new consideration because the data source can reside in the workspace alongside the semantic model. This means workspace permissions might grant broader access than intended. ⚠️

It's similar to User 2 having direct SQL database access – while they might face restrictions in shared reports, they could access unrestricted data by connecting directly to the database.

Unlike Import Mode, which physically stores data within the semantic model, Direct Lake models simply reference data in the Lakehouse or Warehouse. The semantic model functions as a pointer to the data, depending entirely on the Lakehouse or Warehouse for storage and retrieval. 🏢

While RLS implementation occurs within the semantic model and governs report interactions, the actual query execution happens in the Lakehouse or Warehouse, requiring valid connection credentials. 🔑

Watch Out for Workspace Permissions:

• If you give someone "Viewer" access to the master workspace, they can bypass RLS by going straight to the Lakehouse - like giving someone a master key when they only need access to one room

Best Practice: Just like you wouldn't give office visitors unlimited building access, don't give workspace viewer permissions unless necessary. Use App publishing to keep your data secure while still sharing what's needed OR a seperate workspace for RLS governed reports.

Wrapping It Up

Fixed Identity and RLS are like peanut butter and jelly—a combination that just works. Together, they provide secure, seamless, and user-friendly access to data in Microsoft Fabric’s Direct Lake(Storage mode). Users get the data they need (and only the data they’re allowed to see), while administrators can sleep better 😴 knowing their storage is secure and permissions are managed centrally.

If you’re working in an environment where data access needs to be tightly controlled, Fixed Identity and RLS are must-have tools. So, start exploring these features and see how they can simplify your data workflows!

For more details, check out:

• Direct Lake Security and Fixed Identity

• Kudos ❤️ to Zoe Douglas for her amazing comprehensive blog post on the same topic.

  Thanks for Reading !!!

---