Security Improvements

This post has been republished via RSS; it originally appeared at: SQL Server Integration Services (SSIS) articles.

First published on MSDN on Jun 02, 2015

Super User Functional permission:

In the previous release, whoever install the MDS originally, is the server admin. The user will have user id 0. There is no easy way to transfer server admin from one user to the other. It will require DB admin go the user table and change SID on user id 0. There is no easy to have multiple server admins or give server admin permission to a group.

New Super User functional permission is introduced in this release. Super user has the same permission as user id 0 in the previous releases. It can be assigned in same way that assign other functional permission. It can be assigned to user or group.

Model Admin Permission:

In the previous release, model admin permission is implicitly assigned based on some calculation result. If user only have update permission on the model level and do not have any other permission in the model sub tree, the user is model admin. If someday later, user got another explicit permission assign in the model sub tree, such as entity level, the user will lose model admin permission.

New explicit Model Admin Permission is introduced in this release. The admin is available on the model level.

Granular Access Permission:

In the previous release, we have Read-Only and Update permission. It is similar to R/RW permission, where RW permission means all the permission including Create Update and Delete.

And we have been seeing more and more user case requires more granular permission than RW, especially spit delete/create from update. So user can only update the master data but cannot create or delete the data.

So we introduce 4 granular access permission Read, Create, Update and Delete. They can be used together. For example, Create+Update means user can create and update but cannot delete.

Since it does not make sense user only have Create, Update or Delete without Read permission, so when assign Create, Update and Delete permission to user, Read is given automatically. For example, assign user Update permission, the UI will show user has Update and Read permission.

Comparison:

Previous Release

Current Release

User Id 0

User has Super User functional permission

User has update permission on model and doesn’t any permissions in the subtree

User has Admin Permission on model

Read-Only

User has Read Access Permission Only

Update

User has all 4 Access Permission.

Shortcut in UI in All

Deny

Deny

The user with old permission will be converted to new permission, during upgrade.

You can find more information at:

Administrators (Master Data Services)

Model Object Permissions (Master Data Services)

Hierarchy Member Permissions (Master Data Services)

Leave a Reply

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

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.