Dynamics 365 Security: Understanding User vs. Team Security Paradigms

There is a persistent pattern of confusion around the concept of team-based security. When it comes to security roles, we’ve always been told that security is effectively a culmination of inherited rights. Users may obtain these rights or privileges from any of the security roles directly assigned or from the privileges assigned to a team in which the user is a member. While this is true from a certain perspective, it’s always false without additional context. The assumption that team security is the same as user security is the cause of the misunderstanding that has plagued customizers and developers for many years. It’s about time we some Dynamics Kung Fu and destroy this misconception.

What We Think We Know

Having once experienced the same confusion myself about security I can appreciate the frustration that customizers and developers feel when security doesn’t work as expected. Security modeling, in particular, can be quite perplexing because of its less than well-understood functionality and hidden nature. The traditional metaphor for security privileges is they’re like keys. A user only requires a key from at least one source for that user to obtain that privilege. This is true, but it’s also a deception from no one explaining the difference.

The first challenge is that we naturally use the same security paradigm for team roles as we do for user roles. We assume they work the same way and I don’t blame you. I think this expectation is a logical assumption since there doesn’t appear to be any documentation that explains the difference. When things don’t work as expected the first notion is that there’s a bug in the platform that needs to be corrected. Now if you want to classify it as a bug from the purest perspective, you indeed may, but this has been the functionality of the platform since the beginning of the team concept. Let’s first start by breaking your assumption. Team security isn’t the same as user security.

How It Really Works

The team concept implemented in Dynamics was introduced in version 3. I wasn’t in the Dynamics world in those days, but I would assume there was a growing demand for team-based activities and assigning roles to individual users was a cumbersome management mechanism. I imagine it necessitated an extensive use of sharing since only users could own records. I would also guess that clever customers were creating fake users to represent the team concept. The team paradigm introduced a second kind of security principle that like user also had security context within the system.

If you dig deeper into the team security implementation you’ll find that it looks and acts almost identical to users except for one crucial difference – teams have members that operate as delegates. A useful paradigm for team security is an ambassador. When a country sends an ambassador to another country that person represents the leadership of the country, but the ambassador isn’t the leadership. The ambassador may speak on behalf the administration, but their power comes from their association so they can’t just do whatever they want. When a user is part of a team they are an ambassador for that team. From a system perspective, each team is just like a user, but the user isn’t the team.

The Deception of Team Security

One thing I’ve noticed on many projects is the security model tends to be a mix of user and team security. I believe strategically it is usually better to segregate how users get privileges based on the security model. If you have a system where users own records then they should get their privileges from user roles with exceptions from teams and visa versa. What happens when you mix roles you don’t necessarily see how the user is able to perform an action. Often times teams and users have very similar rights which propagate the notion that team security is the same. It’s when you have a security model where only the teams have rights and the user’s don’t have rights that you begin to see your assumptions unravel and the truth punch you in the face.

When a user attempts to perform an action where they don’t have privileges then they will only be able to act as the team. The typical challenge in this scenario is when creating records by default the user is the owner. You can give the team create permission all day long and the user will get a privilege exception every time. How can this be? It’s because the record has to be owned by the team. The team has the privileges, not the user. If you’ve ever assigned a user to a team to a business unit they don’t have access to through assignment you’ll also see that the user can see and do everything that team can see or do. The moment that user attempts to create a record it will be assigned to them and whatever privileges the user has will take effect unless you create a plugin that intercedes and changes the owner.

Paradigm Shift

The one thing I want you to remember moving forward is that teams are like users, but users aren’t teams. A user doesn’t actually inherit privileges from teams, but instead gets an ambassador’s proxy access to them as a delegate. What this means from a practical implementation standpoint is that when you move to a team-based security model you have to understand the implications of proxy privileges and decide what it means primarily when it comes to record creation. When I implement team ownership models I often times have to write create plugins that will change the ownership before the record is saved (since CRM2015 UR-X?, you have to now do this in the pre-operation stage). After you get past the record creation hurdle everything usually feels the same from a user perspective.

If you’re asking yourself why was the team feature implemented this way I have one guess. For better or worse a team is almost the same as a user. If you’re a product team and you want to implement a new feature that’s like an existing feature you might expect they would use the existing feature as a template. By making teams almost identical to users they could use the same query based security model while keeping the implementation complexity down. As long as you know how it actually works I don’t see it as a problem, but if you had assumed user and team security were the same then that is certainly going to cause frustration and confusion..

Blog Reference

Categories: Architecture, Blog

Tags: ,

%d bloggers like this: