Forum Discussion
Update object level security (OLS) roles
Hi All
I have a question about OLS.
Suppose I define two roles for OLS on a dataset:
- roleA - may see Name information
- roleB - may NOT see Name information
I define the roles and in the service I connect to each role a different Azure Active Directory group:
AAD-roleA to roleA and AAD-roleB to roleB.
Now in workspace A I have a Contributor person XX, part of AAD-roleA, and a Viewer person YY, part of AAD-roleB.
So Viewer person YY can NOT see the Name information.
But what if Contributor person XX adds the username of Viewer person yy to roleA in the service?
Then probably Viewer person yy can see the Name information!
Is it possible to prevent Contributor person xx to be able adjust a role?
If we can't prevent it, is it possible to be notified when persons are added to a role in the service?
Does OLS affect a user wirh Contributor permission? In other words, would it have affect if a Contributor is part of roleB? Or can he always see Name information, because he has edit permission for the dataset?
Hope you can help.
regards
Ron
There's a very detailed table available here: Roles in the new workspaces in Power BI - Power BI | Microsoft Docs
If a workspace member was a viewer but had build permissions on the dataset they could build a report on the dataset in power bi desktop or in the service and save to their "My Workspace".
But yes your last sentence is correct.
8 Replies
Trying to pick up a few of your questions:
1) From:https://docs.microsoft.com/en-us/power-bi/admin/service-admin-rls
"Workspace members assigned Admin, Member, or Contributor have edit permission for the dataset and, therefore, RLS doesn’t apply to them."
This also applies to OLS.
2) If a user is a member of more than one role you end up with a UNION of the permissions - it only ever increases access and never takes it away.
3) To my knowledge you can't configure notifications when permissions are changed. (Might be able to wire something up with the API but I'm not familiar enough with it).
Have you considered housing the dataset in one workspace with very locked down access (those who are allowed to change role allocation) but giving users who need it direct build access? They can then build and publish reports ot other workspaces but won't have permission to edit role assignment.
Hi bcdobbs
thnx for your reaction. Let me further explain our situation.
We are storing the datasets in a separate workspace, lets call it WS-A. We have just begun, so there is one dataset now, next will be following soon. For separate user groups we create WS-B, WS-B etc. Users can then read the dataset(s) in WS-A.
So, whay you say in the last line: store the datasets in that separate workspace. Only let some people from IT have access to WS-A to change roles. Contributors in WS-B and WS-C will never be able to change anything in role allocation of the datasets in WS-A, although they have edit permission??So we have a workspace called DW-Models. Myself and one colleague who create the models are member of that workspace.
Everyone else is granted access to the models via:
and given either Read or Read and Build permissions.
Read allows someone to view a report built on top of the dataset in any other workspace.
Build allows someone to build a report on top of the dataset which they could publish somewhere else.
Neither allows them to edit the model in any way.
Thnx bcdobbs
And how is that then related to their role in their own Workspace (WS-B or WS-C) , for instance Contributor or Viewer? Has it use to give the role Viewer build permission?
But nevertheless, what you say is: store the datasets in a separate workspace, let IT handle that and no end-user can mess up /update role information ??
