Microsoft Dynamics CRM offers an extremely flexible security model that you can customize to meet your organization’s security needs. By configuring security settings, you can construct a security and information access solution that will meet the needs of your organization. The process to customize the Microsoft Dynamics CRM security settings requires that you configure your organization structure, decide which security roles your system users (employees) will have, and then define the security privileges associated with each security role. Microsoft Dynamics CRM provides a granular level of security throughout the application. The security model even allows for ad hoc sharing and team-based collaboration on a record-by-record basis. Microsoft Dynamics CRM offers a Web interface for managing, editing, and assigning security roles, and that tool works fine for power users. However, as a developer within Microsoft Dynamics CRM you should understand additional security concepts and tools as you develop your programming customizations.

Chapter 3, showed you the different methods of authentication available when using the Microsoft Dynamics CRM SDK. After your code authenticates a user, the Microsoft Dynamics CRM security model controls the data the user can work with and the actions the user can perform. As a developer, this security model will save you a lot of time because you won’t have to write custom code that manages the application security. The Microsoft Dynamics CRM platform defines each user’s privileges and access to data automatically in the API.

Note

This chapter will mainly focus on security-related programming for Microsoft Dynamics CRM. Refer to Chapter 3, "Managing Security and Information Access," in Working with Dynamics CRM 4.0 (Microsoft Press, 2008) for a more in-depth discussion of the general Microsoft Dynamics CRM security model.

This chapter discusses the different security concepts that you need to understand to successfully develop custom applications and plug-ins for Microsoft Dynamics CRM, including:

Role-Based and Object-Based Security

All users in Microsoft Dynamics CRM must have one or more security roles assigned to them. A security role describes a set of privileges and access levels within the system. Each privilege pertains to one of the following:

• An action against an entity (such as the ability to read or create Accounts)

• A more global action in the system (such as the ability to go offline with the Microsoft Dynamics CRM for Outlook with Offline Access client)

When a user logs on to the system, Microsoft Dynamics CRM looks at the privileges of the user’s assigned security roles and uses that information to determine what the software will allow the user to do and see throughout the system. This is known as role-based security.

A user is considered to hold a privilege if he is assigned a security role with that privilege enabled, but this does not automatically grant the user access to every object the privilege pertains to. Each privilege within Microsoft Dynamics CRM also has associated with it a privilege depth. Whereas a privilege describes what actions can be taken in the system, a privilege depth indicates which specific objects that action can be taken on. Think of this as object-based security. For example, a user may hold the prvReadAccount privilege, allowing him to read accounts, but the privilege depth of the privilege determines which accounts he has read access to. Microsoft Dynamics CRM determines a user’s access to a particular object by considering what the object’s ownership type is, who or what the owner of the object is, and what business unit the user belongs to. Table 4-1 illustrates how privilege depths work.

Table 4-1. PrivilegeDepth Enumeration

Name	Value	Description
Basic	0	Grants user-level access. The user can only perform the privileged action on records he owns or records that are shared with him.
Local	1	Grants business-unit access. The user can only perform the privilege on records in his own business unit.
Deep	2	Grants parent and child business-unit access. The user can perform the privilege on records in her business unit or any business unit lower in the business unit hierarchy.
Global	3	Grants organization-level access. The user can perform the privilege on any record in the system.

Note

Privileges that pertain to non-entity actions (such as Export to Excel) can only be granted with global depth, indicating that the action can be performed by that user if he or she possesses the privilege.