20 Apr

Master Data Services: Security

Because, if the model doesn’t confuse you, the security model surely will.

Model Administrators

These have update permissions on a specific model, or models.   They only have access to areas they are assigned to.  There can be multiple model administrators.

System Administrator

They have update permissions to all models and they can add, update or delete them and there is only a single System Administrator account.

You cannot change the system administrator account using MDS.  You must use SSMS and T-SQL.   The following link explains the process: http://msdn.microsoft.com/en-us/library/ff487048.aspx.

http://msdn.microsoft.com/en-us/library/ff487051.aspx

Users and Groups

In order to get access to MDS a user must have either a Windows domain account or an account on the server where MDS is installed.

To give a user access to MDS you either ad their account  to the list of users in MDS or add them to a group that is in the list of groups in MDS.

To give a user, or group,  the ability to work in the explorer they must be given access to the explorer and model objects.

Functional Area Permissions

There are 5 functional areas:

  • Explorer
  • Version Management
  • Integration Management
  • System Administration
  • User and Group Permissions

Within the Explorer, permissions assigned to models and hierarchical objects, determine access.  In the other areas a user must be a model administrator to view and work on a model.

http://msdn.microsoft.com/en-us/library/ff487014.aspx

Object Permissions

  • Model: Apply to all entities, and collections within the model.  Permissions assigned to a model can be overridden by object permissions.
  • Entity: Apply to the entity’s attributes, collections and explicit hierarchies.
  • Leaf: Apply to all attribute values for leaf members.
  • Consolidated: Apply to all attribute values for consolidated members of an entity.
  • Collections: Apply to all collections for an entity.

Permissions can be broken down into 3 groups:

  • Read-only: Can’t add, remove or update.
  • Update: Can add, remove and update.
  • Deny:  Can do nothing.

There is so variance amongst the different objects but I’m going to take my chances on those.

It is considered a best practice to grant the update permission to the model object and then explicitly permissions beneath it.  If you do not apply these permissions then the objects inherit permissions.

http://msdn.microsoft.com/en-us/library/ee633764.aspx

Navigational Access

This was, to me, a confusing concept.  In essence, what they are doing here is saying, if you get access at a given level, you also get access to some things further up the tree.  These work as follows:

  • Entities: You can read or update the code and name for all members, and read the model name.
  • Attributes: You can read or update the code and name for all members in the entity, and read the model name.
  • Collections: You can read or update the name, code, description and ownerID.  You can also read the model name.

http://msdn.microsoft.com/en-us/library/ff714017.aspx

Hierarchy Permissions

Microsoft say’s they’re optional.  I’m going with that.  Here’s a link.

http://msdn.microsoft.com/en-us/library/ee633750.aspx

Overlapping User And Group Permissions

  • Deny overrides all other permissions.
  • Update overrides Read-only.

Overlapping Model And Member Permissions

  • Deny overrides all other permissions.
  • Read-only overrides Update.

Here’s to hoping that’s most, if not everything, and that I didn’t blow anything too terribly.

Leave a Reply

Your email address will not be published. Required fields are marked *