Microsoft has just released a white paper on their security modeling features which you can get to from this link. In this white paper Microsoft goes through in detail the different features within Dynamics CRM that allow users to drive security and different access levels to data with CRM. It also talks about the implications associated with these features functioning at high volumes, and guidance on modeling Dynamics CRM for scale.
With all of the flexible security features that Microsoft offers, it’s very important to plan out your strategy for your security. Security is one of the last things we see that is often overlooked in a lot of deployments but is one of the most critical pieces in a successful deployment. You can build the most amazing custom solution, but if you haven’t thought out who will be accessing your system, how those users will access your system, and what permissions they’re going to need, then your project could be a failure.
Microsoft breaks down user access to Dynamics into two categories:
- Authentication: Determining who the user is and confirming they are who they say they are
- Authorization: Determining whether the authenticated user is entitled to access the system and what within the system they are permitted to see or do
The whitepaper goes into details about Authorization, and not Authentication, as Authentication can be handled by a variety of different technologies which have detailed documentation of their own.
The whitepaper discusses a few common business scenarios. From this discussion, it’s easy to identify the different categories or levels of interacting with CRM data, and the different values of those interactions and what it means for dealing with your customers. Categorizing your user access needs into these high level buckets is a first start to understanding and developing a security authorization strategy for your deployment.
Dynamics CRM Access Control Objects:
The different Access Control Options made available out of the box are discussed:
- Sharing with Users / Teams
- Sharing is a good option for exception cases but when your database size and number of records grow, this becomes an unmanageable solution.
- There’s also the concern of a performance impact if you have a lot of shared records in a large database, as each record that is shared, also gets a Sharing Record created increasing the size of your database.
- Also pay attention to the Cascade settings as sharing a parent record could drastically increase the size of your database if the Sharing is cascaded down to child records.
- Sharing with Teams reduces the overhead and increase in database size as sharing with one record, ends up sharing with all users in that team.
- However, there is still a performance concern from the overhead associated with calculating access to each record.
- The whitepaper discusses in length how Sharing is implemented in CRM and why you should carefully consider if Sharing should be used in your deployment or not.
- Record Ownership (User / Team / Org / Business Unit)
- Discusses the different types of ownership types per entity.
- Team Ownership allows for ease of providing multiple people access to a set of records by adding or removing them from one team, versus sharing with each of the records.
- Business Unit Privileges
- Business Units are discussed including how setting up a solid hierarchy of your organization’s groups that will be accessing CRM is a key piece to planning out your security plan.
- Organization Privileges
- These are Organization Owned entities that users can either have access to or not.
- The granularity of security for User Owned entities do not apply here.
- Performance benefits for Organization Owned entities exist as individual access checks are not required other than a user or team is allowed access to the record.
- Field Level Security (Access Control to Fields)
- If you cannot break out secure information into separate entities that you can lock down, Field Level Security would be required to lock down sensitive pieces of information in a record.
Scalability Characteristics of Dynamics CRM:
The white paper then discusses scalability characteristics of these CRM elements. Instead of discussing details of each security model, the document goes into the approach used for each so that the scalability can be appreciated.
Dynamics CRM caches a lot of information to optimize the user experience and improve performance. These include metadata, security roles / business units or a user, security role / business units of teams, and team membership. This information is cached by each application server separately when the information is first requested.
It’s interesting to note that there are a couple things that could degrade performance and should be something to watch out for when you’re building out your solution:
- Users are associated with a lot of teams
- A large amount of users logging in at the same time
- Frequently changing team membership
- Frequently updating user details
The whitepaper says that performing the action in the last bullet above regarding updating user details forces the application servers’ caches to flush the user’s information with each update forcing it to be reloaded the next time it’s requested, which is an expensive process.
As discussed previously above, the white paper talks at length about the implementation of Sharing in Dynamics CRM, and the fact that you should carefully consider using it in high volume environments. The document states that Team Ownership is a great alternative that users should consider instead of using Sharing extensively. The table below details some of the implications of Team Ownership.
Just like anything else in the system, Business Units also succumb to the “too many could be a bad thing” theory. Microsoft states that having too many business units (>1000) could have an impact on system performance.
Granular access to records (e.g., sharing) is more expensive in terms of performance compared with organization wide privileges (e.g., making entities Organization Owned). However, all deployments we’ve worked with require at least some ability to define security at a granular level. This white paper goes into details about where performance issues can come into play with overusing granular level access to records, and points out that if you can avoid it for some areas of your deployment, you should try to, as this will reduce the probability of running into performance issues down the road as the size of your environment grows.
The table below gives a good overview of the different security features offered by Dynamics CRM and their functionality:
The main takeaways I got from reading this whitepaper are:
- Use Sharing sparingly and only in exception cases as it can be costly regarding performance – try to use team ownership instead
- Keep the number of Business Units under 1000
- Pay attention to the number of teams a user is associated with and keep this to a realistic number
- Monitor the login pattern of your users as many logging in at the same time could impact overall scalability
- Do not update user team membership frequently
- Try not to update user details frequently
If you’re planning on rolling out a Dynamics CRM solution, this whitepaper is a must read. It goes into great detail how each of the security features in CRM work and the implications of each in regards to scale and performance.