CRM 2011: Understanding Security Model - Part 1

Security Model is a very integral component of Microsoft Dynamics CRM 2011 platform.

This post gives an overview of the Security Model in Microsoft Dynamics CRM 2011.

• Role based Security
• Field level Security
• Object based Security
• Role based Forms
• Security Principals
• Security Dependencies
• Authentication Methods

Role based Security

Users and Teams are assigned security roles in Microsoft Dynamics CRM 2011 which define their privileges and access level, or in other words it defines what user/team is authorised to perform in CRM. 

Role based Security has two components

1. Privileges
2. Access Level

Privileges

Microsoft Dynamics CRM platform validates the user request to perform a specific operation against the privileges (defined in security role) assigned to a user and accepts/rejects based on it.

Common privileges available per entity are 

• Create - Ability to create entity records.
• Read - Ability to read entity records.
• Write - Ability to modify entity records.
• Delete - Ability to delete entity records.
• Append - Ability to associate a selected entity record to another entity record.
• Append To - Ability to associate another entity record to this entity record.
• Assign - Give ownership of entity record to another user/team.
• Share - Give access to entity records to other user/team. 

Access Level

Access Level uses the ownership of the object to determine if a user can apply privileges on a specific object.

Microsoft has classified Access Levels as

• None
• User/Team
• Business Unit
• Parent: Child Business Units
• Organisation

In short

• Privileges determine "WHAT" a user can perform on an object.
• Access Level determines on "WHICH" object a user can perform this action.

Field Level Security

Microsoft Dynamics CRM 2011 platform supports field level security which allows us to grant or restrict access to specific fields at three levels

• Read - Read-only access to field's data
• Create - Can add field's data when creating a record
• Update - Can modify field's data

We can use combination of these three levels to grant/restrict access to specific users or teams.

for example, if a security profile is configured to grant "Read" and "Create" permissions to a specific field then users or teams added in that profile can add data to field when creating a new record but once record has been saved then it will become read-only field for them because they don't have update permission.

Likewise, you can choose to grant

• No permissions - Users or Teams will not be able to see data in that field (it will appear as masked field with no visibility to data)
• "Read" and "Update" permissions but not "Create" - Users or Teams will be able to read or modify data in that field but will not be able to add data to field when creating a record.

and so on ...

Field level security is always in force

• User/Team accessing data through Application
• User/Team accessing data through webservices or custom code
• User/Team accessing data through reports

For example if a user does not have access to a specific field and custom code (under that user's impersonation) tries to access that field's data, CRM platform will return null so in this case custom code will not know if this field is actual null or data unavailable to this user because of field level security.

Easy steps to set up field level security

• Enable "Field Security" for a specific field so that it becomes available to be configured in Security Profile(s)
• Create/Configure Security Profile
• Add Users/Teams to that Profile

Field level security is only available for custom fields/attributes - not for system or built-in fields/attributes.

Object based Security

Microsoft Dynamics CRM 2011 security model supports object or data sharing.

Users with "Share" rights on an entity can share entity records with other users or teams which can override their respective access level restrictions. It is important to understand that sharing cannot grant privileges if a user has no privileges on that entity.

If a user does not have some level of access on an entity then sharing cannot provide that privilege.
like for example, if a user's role does not grant him or her "Read" privileges on Contact entity then sharing a contact will not grant him or her read privileges on contact entity.

When sharing, user can grant certain access rights so that user or team (with whom the record is shared) can perform actions on that record or object.

Continued at Understanding Security Model - Part 2