data-security-setup-ols.md

uid	title	author	updated	applies_to
data-security-setup-ols	Setup or Modify OLS	Kurt Buhler	2023-03-02	editions edition Desktop edition Business edition Enterprise

Setup or Modify Object-Level Security (OLS)

---

OLS is changed by adjusting the Roles or Object Permissions defined for Tables or Columns. Object Permissions are TOM Properties visible with the Object Level Security property that can be either Default (no OLS; functionally similar to Read), Read, or None. OLS differs from RLS in that it does not filter data, but prevents execution of the object and all dependents. This means any relationship or measure that references the object where Object Level Security is set to None will return an error upon evaluation.

---

• About Data Security and RLS/OLS: A functional overview of RLS & OLS.
• Modify/Setup an RLS Configuration: How to configure RLS in a dataset.
• Modify/Setup an OLS Configuration (This Article): How to configure OLS in a dataset.
• Testing RLS/OLS with Impersonation: How to easily validate Data Security with Tabular Editor.

---

Configuring OLS in Tabular Editor 3

Below is an overview of common changes one might make to existing OLS. Additionally, strategies for configuring OLS for atypical objects (Measures, Calculation Groups) are described, below:

---

1. Remove a Role

To remove a Role from the model, you can simply delete the Role object with Del or by right-clicking and selecting 'Delete'.

Figure 1: Deleting a Role in the model.

Note

All users assigned to this role will no longer be able to see model data, so long as at least one other Role exists.

---

2. Add a New Role

To add a Role to the model:

1. Right-Click the 'Roles' Object Type: This will open the dialogue to let you create a new Role.
2. Select 'Create' > 'Role': Name the new role.

Figure 2: Creating a new Role in the model.

3. Set the Model Permission Property to Read: This is necessary for Power BI datasets.

Figure 3: Setting the Model Permission property is necessary for Power BI.

4. Set Permissions: Set RLS Table Permissions and/or OLS Object Permissions, as described, below.

---

3. Remove OLS

To remove OLS from the model, all Columns and Tables must have their Object Level Security property configured to Default for all roles. To remove Data Security from the model, all Roles must be deleted.

Figure 4: The Object-Level Security property can be found in the Properties pane when selecting a Column or Table. The property does not exist for Measures, Relationships and other Object Types.

Note

Once all roles are deleted, all users will be able to see all data so long as they have Read permissions on the dataset.

---

4. Setup or Change OLS

Setup or Modification of OLS is trivial for Columns and Table. You just have to select the object and navigate to the Object Level Security property, using the dropdown to change the property to the desired value.

Figure 4: The Object-Level Security property can be changed with an adjacent drop-down, allowing selection of Default, None or Read.

---

5. Combine OLS with RLS

Successfully combining RLS with OLS requires designing a model and Data Security / Access Management strategy that align. Since RLS and OLS cannot combine across roles, this means if you plan on implementing both RLS and OLS, users are limited to a single role.

---

6. Configure OLS for Measures

Natively, OLS works only on Columns, Tables and their dependents; there is no Object-Level Security property for measures. However, since OLS also applies to dependents, it is possible to design OLS that works on measures via disconnected tables or calculation groups. To do this, the measure DAX has to be altered to evaluate a column or calculation group configured with RLS. If the Object-Level Security property of that object is None, then the Measure will not evaluate.

See also this article by SQLBI which explains this approach in detail.