Object-Based Security

Object-Based Security

Object-based security applies to individual instances of entities and is provided by using access rights. The relationship between an access right and a privilege is that access rights apply only after privileges have taken effect. For example, if users do not have the privilege to read accounts, they will be unable to read any account, regardless of the access rights another user might grant them to a specific account through sharing.

 

Access Rights

Access Rights

An access right is granted to a user for a particular entity instance. The following table lists the descriptions for these access rights.

Access rightEnumeration nameDescriptionReadReadAccess Controls whether the user can read an entity instance.WriteWriteAccess Controls whether the user can update an entity instance.AssignAssignAccess Controls whether the user can assign an entity instance to another user.AppendAppendAccess Controls whether the user can attach another entity instance to the specified entity instance. The Append and Append To access rights actually work in combination with one another. Every time that a user attaches one entity instance to another, the user must have both rights. For example, when you attach a note to a case, you must have the Append access right on the note and the Append To access right on the case for the operation to work.Append ToAppendToAccess Controls whether the user can append the entity instance in question to another entity instance. The Append and Append To access rights work in combination with one another. Every time that a user attaches one entity instance to another, the user must have both rights. For example, when you attach a file to a note, you must have the Append access right on the file attachment and the Append To access right on the note for the operation to work.ShareShareAccess Controls whether the user can share an entity instance with another user or team. Sharing gives another user access to an entity instance. For more information, see Sharing.DeleteDeleteAccess Controls whether you can delete an entity instance.

Create Access

The right to create an instance of an entity is not included in the previous table because this right does not apply to an individual instance, but instead to a class of entities. Therefore, Create is handled as a privilege instead of as an access right. By default, the user who creates an entity instance will have all rights on that entity instance, unless his or her other privileges forbid a specific right.

The Create privilege controls whether you can create an entity instance. You can have the Create privilege with Local, Deep, or Global access level, and you will be able to create instances for other users. However, you can create instances for yourself only if you have Create and Read privileges.

For more information about dependencies that relate to Create privileges, see Security Dependencies.

 

Sharing Objects

Sharing Objects

Sharing lets users give other users or teams access to specific customer information. This is useful for sharing information with users in roles that have only the Basic access level. For example, in an organization that gives salespeople Basic read and write access to accounts, a salesperson can share an opportunity with another salesperson so that they can both track the progress of an important sale.

For security reasons, it is important to develop the practice of sharing only the necessary objects, or entity instances, among the smallest set of users possible, and to grant only the minimum access required for users to do their jobs.

Microsoft Dynamics CRM provides the following sharing capabilities:

• Share. Any user who has share privileges on a given entity type can share instances of that type with any other user or team in Microsoft Dynamics CRM. 
• Share rights. When you share an entity instance with another user, you can indicate what access rights (Read, Write, Delete, Append, Assign, and Share) you want to grant to the other user for that entity instance. Access rights on a shared entity instance can be different for each user with whom the entity instance is shared. However, you cannot give a user any rights that he or she would not automatically have for that type of entity based on the role assigned to that user. For example, if a user does not have Read privileges on accounts and you share an account with that user, the user will be unable to see that account.
• Modify share. You can modify the rights granted to a shared entity instance after it has been shared.
• Remove share. When you share an entity instance with another user or team, you can stop sharing the instance at a later date. After you remove sharing for an entity instance, the other user or team loses access rights to the instance.

Tip   Use the GrantAccess, ModifyAccess, and RevokeAccess messages for sharing.

A user might have access to the same entity instance in more than one context. For example, a user might share an entity instance directly with specific access rights, and he or she might also be on a team in which the same entity instance is shared with different access rights. In this case, the access rights that this user has on the entity instance is the union of all the rights.

For a list of entities that support sharing, see the GrantAccess message.

Sharing and Inheritance

If an entity instance is created and the parent entity instance has certain sharing properties, the new entity instance inherits those properties. For example: Joe and Mike are working on a high priority lead. Joe creates a new lead and two activities, shares the lead with Mike, and selects cascade sharing. Mike makes a telephone call and sends an e-mail regarding the new lead. Joe sees that Mike has contacted the company two times, so he does not make another call.

Sharing is maintained on individual entity instances. An entity instance inherits the sharing properties from its parent and also maintains its own sharing properties. Therefore, an entity instance can have two sets of sharing properties—one that it has on its own and one that it inherits from its parent.

Removing the share of a parent entity instance removes the sharing properties of objects (entity instances) that it inherited from the parent. That is, all users who previously had visibility into this entity instance no longer have visibility. Notice that certain child objects might still be shared to some of these users if they were shared individually.

 

Assigning Objects

Assigning Objects

Anyone with Assign privileges on an entity instance can assign that object to another user. When an entity instance is assigned to a new user, the new user becomes the owner of the entity instance and its related entity instances. The original user loses ownership of the entity instance but automatically shares it with the new owner.

In Microsoft Dynamics CRM 4.0, the system administrator can decide for an organization whether entity instances should be shared with previous owners or not after the assign operation. If the Share with previous owner is chosen then after the assign operation the previous owner shares the entity instance with all access rights. Otherwise the previous owner does not share the entity instance and therefore may not have any access to the instance, depending on his or her privileges.

For a list of entities that support Assign see the Assign message.