MDS security: model permissions, member access, and what replaces them

Security is the part of an MDS migration that people discover late. The data model gets all the attention. Entities, attributes, hierarchies, subscriber views, those show up on every project plan. Then someone asks who is allowed to edit the supplier master in the new tool, and the room goes quiet, because in MDS that answer lived in three different places and came from Active Directory.

None of it migrates. There is no export that carries MDS security into another product. What you carry over is the intent behind it, and you rebuild that intent in whatever you move to. That sounds like a chore. In practice it is the cleanest part of the whole migration, because it forces you to write down access rules that have been drifting for years.

What MDS security actually was

MDS stacked three independent mechanisms, and you needed all three lined up correctly for a user to do anything useful.

Functional area access decided which parts of the application opened at all. Explorer for the data stewards. Integration Management for the people loading staging tables. Version Management, System Administration, and User and Group Permissions for the administrators. A user with no functional access saw a stripped-down screen no matter what their data permissions said.

Model object permissions were the real workhorse. You assigned Read-only, Update, or Deny against a model, an entity, or an attribute group, for a given AD user or group. This was where you said the procurement team can update suppliers but only read products. The three levels cascaded: set it on the model and it flowed down unless you overrode it lower.

Hierarchy member permissions went one level finer. Inside a derived hierarchy, you could grant Read-only, Update, or Deny on specific members, which let a regional manager edit only the suppliers under their region. This was MDS doing row-level security, and it was the layer that caused the most confusion and the most support tickets.

Underneath all three, MDS held no identities of its own. Every user and group came from Active Directory. That kept sign-in simple and tied your master data security to a directory that the MDM team usually did not control.

The part most teams got wrong

Deny always won. If a user picked up Update from a group and Deny from another, the Deny took effect, and tracing why someone could not edit a field meant unpicking every group they belonged to. I have watched an administrator spend an afternoon on exactly this, only to find a Deny set on an attribute group three years earlier by someone who had left the company.

The other quiet problem was that none of these grants were governed. A change to model object permissions took effect immediately, with no review and no record beyond whatever the directory logged. Master data security drifted the same way master data does, one well-meaning grant at a time, until nobody could state with confidence who could change what.

What maps cleanly, and what does not

Two of the three MDS layers translate almost directly into a modern role-based model. One does not, and being honest about that up front saves a nasty surprise in user acceptance testing.

The honest gap is hierarchy member permissions. Most MDM tools, Primentra included, scope access to the model, the entity, and the attribute, not to individual rows. Before you treat that as a dealbreaker, check whether you actually relied on member permissions or just configured them once and moved on. A surprising number of MDS deployments did the latter. If you do need a real boundary, say a region or a business unit that must not see each other's records, the durable answer is to model that boundary as separate entities and grant per-entity access, rather than leaning on a row-level feature that varies wildly between tools.

How a role-based model expresses the same control

Here is how it works in Primentra, which is representative of where this category has landed. Permissions belong to roles, never to individual users. To know what a person can do, you read their role memberships, not a per-account access sheet. That single decision is what makes the system auditable at two hundred users instead of ten.

Each role gets granular CRUD at model and entity scope, Create, Read, Update, Delete, plus a Moderator flag for configuration access. At attribute scope the choice is None, Read, or Write. Permissions cascade exactly as MDS model object permissions did: set on the model, inherited by every entity and attribute below, overridden where you need an exception. The hero diagram at the top of this post shows that cascade, with a model default loosened on one entity and tightened on one field.

When someone belongs to more than one role, the most permissive combination wins. This is the opposite of the MDS Deny-wins rule, and it is far easier to reason about. You never hunt for a hidden Deny. If a user cannot do something, the reason is simply that no role grants it. Because the data lives in plain SQL Server tables, you can answer the question directly:

SELECT
    p.Scope,
    p.TargetId,
    MAX(CAST(p.CanCreate   AS INT)) AS CanCreate,
    MAX(CAST(p.CanRead     AS INT)) AS CanRead,
    MAX(CAST(p.CanUpdate   AS INT)) AS CanUpdate,
    MAX(CAST(p.CanDelete   AS INT)) AS CanDelete,
    MAX(CAST(p.IsModerator AS INT)) AS IsModerator
FROM Users u
JOIN RoleMembers rm ON rm.UserId = u.Id
JOIN Roles       r  ON r.Id      = rm.RoleId
JOIN Permissions p  ON p.RoleId  = r.Id
WHERE u.Email = @Email
GROUP BY p.Scope, p.TargetId;
-- MAX() is the OR-union: the most permissive role wins.

The control MDS never had

MDS conflated two rights that should be separate: the right to make a change and the right to bless it. Anyone with Update edited live data, and there was no built-in step between an edit and the data going live.

A role-based model can split those apart. In Primentra the right to approve is its own grant, set on a role and tied to specific entities, and it is independent of CRUD. A reviewer can approve supplier changes without being able to author them, and an editor can propose changes without the power to wave their own work through. Entities that require approval lock a record while a change is pending, so two people cannot quietly edit around each other.

The other thing MDS lacked is a record of the permissions themselves changing. Every grant, every revocation, every CRUD flag flipped on a role belongs in the audit log next to the data changes, with who did it and when. That is the difference between answering an auditor in three seconds and starting an investigation.

What to ask MDM vendors about access control

When you evaluate a tool to replace MDS, put security on the demo agenda and ask these four questions:

Frequently asked questions