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
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
- Privileges
- 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
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
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.
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
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
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
