Data Engineering

Master Data Services Permissions Guide

Posted on 13th May 201521st April 2020 by Jeremy Kashel

13
May

I’ve had a few questions recently on various projects around the Master Data Services Model Object permissions. At a simple level they can be quite easy to master, but can get more complex as you try and combine the different permissions to create your desired security setup.

This guide assumes that you’ve set the Functional Area Permissions and given the user or group access to the Explorer functional area. The tables below show the different permissions that can be applied to each object within a model:

Model Permissions

This example shows the MS sample Customer model, which I’ve named as Customer Sample.

Permission	Action	Result
Update		The user will be a Model Administrator, meaning that they can add/delete/modify entities and access all data within each entity in the model. If they also have access to the System Administration functional area, then they will be able to actually add/edit/delete entities and other model objects.
Read Only		The user will be able to read the data within each entity in the entire model.
Deny		The user will not be able see the model.

Entity Permissions

This example shows the entities that are contained within the same Customer Sample model.

Permission	Action	Result
Update		You can add/modify and delete members within the entity, in this case “Big Area”.
Read Only		You can read all members within the entity.
Deny + Read Only on Model		This is where it starts to get interesting. By having Read Only on a Model it means that you will have access to all entities. But by setting Deny on a specific entity, the user will now not see that entity in the drop down list.
Update + Read Only on Model		This will result in Read Only for all entities, but the user will be able to add, edit and delete members within the Big Area entity.

Member Type Permissions

Depending on the entity, you could have both “Leaf” Member Type or Consolidated Member Type permissions (see here for the difference between the two). This table covers Leaf Members:

Permission	Action	Result
Read Only		Only choosing Read Only at the “Member Type” level will cause the same result as choosing Read Only on the entity. Therefore you will be able to read all members in the entity.
Update		You can add/modify and delete members within the entity, in this case “Big Area”.
Deny		The user will not be able see or access the entity.

As you can see, if you only have Leaf Members within the entity, then the permissions are the same as if you are setting them at the entity level.

Attribute Permissions

Permission	Action	Result
Read Only		With just Read Only on one attribute, this will actually result in the user being able to view the whole of the Area entity, even though the Read Only permission has been set on one attribute.
Update		The user will be able to view the whole entity, but will only be able to modify the Big Area attribute on existing members.
Deny		The user will not be able to see anything, as Deny on just an attribute is not enough to give the user access to the entity. See the next row for how to correct this.
Deny + Read Only on Entity		The user will be able to view the Area entity, but the Big Area attribute will not be visible.
Update + Read Only on Entity		The user will be able to view the entity, but will only be able to update the Big Area attribute.
Read Only + Update on Entity		The user will be able view, add and edit members, but will not be able to specify a value for the Read Only attribute. The user can, however, delete members.

The last three examples really highlight how combining MDS permissions can be powerful. Lets look at these in more detail:

Deny on Attribute + Read Only on Entity

Setting Deny on the Big Area attribute, but Read Only on the entity will result in the user seeing the following:

The “Big Area” attribute is completely missing from the MDS Explorer grid.

Update on Attribute and Read Only on Entity

On the other hand, setting Update on the Big Area attribute and Read Only on the Area entity will result in the user seeing the following when editing a member in the Area entity:

The two highlighted attributes (Name and Code) are both Read Only as we set the entity to be Read Only. The user can edit the Big Area attribute for each member, as we gave the user Update permission on that attribute.

Read Only on Attribute and Update on Entity

Finally, in the last example we have Read Only on the Big Area Attribute, but Update on the Area Entity. This means the user cannot specify a value for the Big Area attribute:

So there we have it! Hopefully this post will be useful – as you can see the MDS Object Model permissions can be very granular and should be able to cover most of the scenarios that you need.