CRM 2011: Understanding Security Model - Part 2

This post is the continuation of my earlier post titled Understanding Security Model - Part 1

 

In this post we will cover following topics of Security Model

• Role based Forms
• Security Principals
• Security Dependencies
• Authentication Methods

Role based Forms

Microsoft Dynamics CRM 2011 allows us to have multiple forms per entity, this equips us to enhance the user experience by exposing different data fields/content to different users based on the security role assigned to them.

 

We can have role based forms/pages without having to create stop-gap solutions and the CRM platform determines the page content visibility based on the security role assigned to a user.

 

Users can see all the forms available to their roles and have the ability to switch between the forms, we can also do client-side scripting to switch forms based on different business rules (can be data driven rules).

 

Overall, client-side scripting to hide/show controls on a form is more efficient approach rather than using different role based forms as it does not require page refresh (switching between forms require page refresh).

 

This feature is automatically enabled for all entities in the system.

 

Security Principals

Microsoft defines "Security Principal" as a user or team who owns or have rights to access an entity instance(record). Entities are either owned by Organization or User/Team.

 

Examples of User/Team owned and Organization owned entities are

• User/Team owned entities
• Account
• Contact
• Case
• Organization owned entities
• Product
• System User
• Price List

In principal, reference entities should be Organization owned and other entities should be User/Team owned so that a specific user or team owns an entity instance. However an architect can design it differently based on business needs and other preferences.

 

Entity records are assigned to a specific a user or a team, who is the owner of the entity record.

Entity instances can also be shared with other users or teams so that they can get access to the entity instance/record and perform actions on it, sharing a record with a team allows the members of that team to access/perform actions on that record.

 

Security Dependencies

As discussed in the part 1, every user in Microsoft Dynamics CRM must be assigned a security role which defines their respective access rights.

There are some security dependencies and to perform a particular operation, it is required to grant more than one access right.

 

Consider this example

 

"Create" access right is required to create an entity instance, however user must also be granted "Read" access right on that entity to enable the user to successfully create an entity instance or record. So in this case "Create" access right is dependent on "Read" access right.

 

Another type of security dependency exists when an object is dependent on another object OR in other words when object is subordinate of another object.

 

Like for example, a Case object cannot exist without customer entity(Account or Contact) so in order to create an instance of Case object, user must have rights to attach it to a customer entity instance (Account or Contact). User must have the following access rights in addition to "Create" and "Read" access rights to be able to create an instance of a Case object.

• "AppendTo" access right on Customer entity (Account or Contact) so that user can attach an object/entity instance to Account or Contact entity instance.
• "Append" access right on Case entity so that a user can attach Case object to another entity.

Authentication Methods

Microsoft Dynamics CRM 2011 offers two authentication methods

• Active Directory Authentication
• Claims-based Authentication

Active Directory Authentication

Microsoft Dynamics CRM sends request to Active Directory for authentication and IIS manages authentication for CRM web application, on the other hand if CRM SDK application sends request to Active Directory for authentication then WCF manages the authentication process.

Claims-based Authentication

Microsoft has created Windows Identity Foundation(WIF), a security framework which implements claims-based authentication.

Microsoft Dynamics CRM 2011 uses WIF framework for claims-based authentication.

 

Claims-based authentication presents user's identity to the application as a set of claims, Microsoft Dynamics CRM 2011 then passes on that claim to Security Token Service (STS).

The STS is then responsible for actual authentication, not Microsoft Dynamics CRM.

 

To implement claims-based authentication, we need STS to be hosted on the server, it can be based on Active Directory Federation Services (ADFS) 2.0

 

For further details, please refer to Microsoft's official training material.