Role-Based Security
The fundamental concept in role-based security is that privileges are assigned to defined categories of users (known as roles) rather than to individual users. When a user is assigned to one of these roles, he or she is assigned the set of privileges associated with that role. A user who is not assigned to a role does not have any privileges.
In Microsoft CRM, a role describes a defined set of responsibilities (or tasks to perform) within the organization, for example, a sales representative. Each role is assigned a set of privileges that are relevant to the performance of the tasks defined for that role. All users must be assigned to one of these predefined roles.
A privilege authorizes the user to perform a specific action on a specific object type. Privileges apply to an entire class of objects, rather than individual instances of objects. For example, if a user does not have the privilege to read accounts, then any attempt by that user to read an account will fail. Each privilege can have up to four access levels: Basic, Local, Deep, and Global.
In Microsoft CRM, privileges are predefined on a system-wide basis during setup. There are over 200 different privileges in Microsoft CRM. You can see the complete list of privileges available in the Microsoft CRM application in Appendix A.
Microsoft CRM uses privileges as the core of the underlying security check. Privileges are "built in" to the product and are used throughout the application and platform layers. It's not possible to add or remove privileges, nor is it possible to change how privileges are used to grant access to certain functionality, but it is possible to construct new roles from the existing privilege set.
The following table describes the classes used for managing role-based security.
| Class | Description |
| CBizPrivilege | Contains methods to manage business privileges |
| SecRole | Contains methods to manage security roles |
For more information about dependencies between privileges, see Security Dependencies.
For information about security best practices, see Security Best Practices.