Field-Level Security in Microsoft Dynamics CRM
Recently I came across the blog article Field-Level Security in Microsoft Dynamics CRM : Options and Constraints (at http://blogs.msdn.com/crm/archive/2009/11/16/field-level-security-in-microsoft-dynamics-crm-options-and-constraints.aspx) which talks about restricting attribute level access to certain users based on the different access channels for users to Microsoft Dynamics CRM.
On the client side, one of these ways can be used –
a. Passing an indicator to the field to display to the user that they user cannot view the attribute e.g. ‘******’, ‘Restricted’, ‘Not Authorized’.
b. Making fields read only or hidden if a user is not authorized to view them.
Server Side Restriction –Two strategies are basically proposed:
1. Role based filtering - If the user does not have a role that is entitled to access the attribute then it will be restricted.
An advantage of role based filtering (and a reason for its simplicity) is that the access to an entity’s attributes can be defined without needing to access the data in the entity’s records, and that the definition will apply uniformly across the instances of an entity for a particular user.
2. Rule based Filtering- Building extra rules into the query that is used to request information from the CRM platform. Alternatively, it may be necessary to filter after retrieval, though this results in the additional performance overhead associated with having retrieved data that will be filtered out before information is displayed to the user.
Consider a scenario in which business rules require that all records with a customer turnover:
• Greater than or equal to £1M have the profit field restricted
• Less than £1M have the profit field displayed
Because the platform cannot return the profit for one subset of the customers but hide it for the others, it is necessary to query the platform to return the profit for all customer records and then to filter out the values of the returned records set afterwards before returning it for display at the client.
Following is a brief explanation of the recommended mechanisms for restricting attribute level access in case of server-side access to entities:
1. Plug-ins and CRM SDK web service: Scenarios that require restricted access to data must account for the different ways that forms are used (Create, Retrieval, and Update).
During the creation of a record, for example, it is important to prevent accidental or malicious entry of unauthorized data. This can be accomplished by implementing the appropriate logic within a Pre-Create Plug-In. To prevent a particular user from setting specific attributes, remove those attributes from the InputParameters collection.
DynamicEntity updateValues = (DynamicEntity)context.InputParameters.Properties["Target"];
If( ([USER NOT AUTHORISED] ) && updateValues.Properties.Contains[“ATTRIBUTE_NAME”])
{
updateValues.Properties.Remove[“ATTRIBUTE_NAME”]);
}
During Retrieval, it is important to hide data from unauthorized users. This can be accomplished by using either a Pre-Retrieve or Post-Retrieve Plug-In. It is also necessary to provide a Pre-Update Plug-In to prevent unauthorized users from updating record fields that those users are not authorized to view or to update
2. Access via Views/Advanced Find - The underlying queries that these user interface elements use to retrieve data are sent to the platform via one of two types of messages, either by FetchXML requests sent through the Execute message or by RetrieveMultiple messages. Both types of messages must be filtered to ensure data security.
3. CRM Metadata web service – If the metadata service is used, it is not possible to hide the fact that information of a certain type is captured for a particular entity, and therefore other mechanisms should be used so as to hide the actual data captured against that attribute.
4. Export-to-Excel feature ensures that users can only export the data to which they have access. After enabling field-level security by using the plug-in approach, it is important to consider the Export-to-Excel capability to prevent data restricted through the UI from being accessed in this way.
Applying field-level security is more problematic with dynamic worksheets however, because the data is retrieved directly by the Excel worksheet at the client from the database by using the filtered views that the CRM product creates and exposes. There is no supported way to intercept or alter the data returned by the CRM provided Filtered Views. As a result, the best option available is to prevent direct access to the database Filtered Views altogether by the user from the client
5. To secure data that can be accessed by using reports, available options include:
• Disabling Reports access for roles that require field-level security.
• Disabling report creation for roles that require field-level security. Provide pre-defined custom reports for those users.
6. To secure direct access to Database Filtered Views, available options include:
• Denying user membership to the CRM Reporting Group.
7. Access via Outlook Synchronization and the Offline Client - If any of the data shared with Outlook (i.e. contacts, appointments, tasks) or the offline client needs to be limited at a field level for particular users, then those users must not be able to use the CRM Outlook add-in.
On the client side, one of these ways can be used –
a. Passing an indicator to the field to display to the user that they user cannot view the attribute e.g. ‘******’, ‘Restricted’, ‘Not Authorized’.
b. Making fields read only or hidden if a user is not authorized to view them.
Server Side Restriction –Two strategies are basically proposed:
1. Role based filtering - If the user does not have a role that is entitled to access the attribute then it will be restricted.
An advantage of role based filtering (and a reason for its simplicity) is that the access to an entity’s attributes can be defined without needing to access the data in the entity’s records, and that the definition will apply uniformly across the instances of an entity for a particular user.
2. Rule based Filtering- Building extra rules into the query that is used to request information from the CRM platform. Alternatively, it may be necessary to filter after retrieval, though this results in the additional performance overhead associated with having retrieved data that will be filtered out before information is displayed to the user.
Consider a scenario in which business rules require that all records with a customer turnover:
• Greater than or equal to £1M have the profit field restricted
• Less than £1M have the profit field displayed
Because the platform cannot return the profit for one subset of the customers but hide it for the others, it is necessary to query the platform to return the profit for all customer records and then to filter out the values of the returned records set afterwards before returning it for display at the client.
Following is a brief explanation of the recommended mechanisms for restricting attribute level access in case of server-side access to entities:
1. Plug-ins and CRM SDK web service: Scenarios that require restricted access to data must account for the different ways that forms are used (Create, Retrieval, and Update).
During the creation of a record, for example, it is important to prevent accidental or malicious entry of unauthorized data. This can be accomplished by implementing the appropriate logic within a Pre-Create Plug-In. To prevent a particular user from setting specific attributes, remove those attributes from the InputParameters collection.
DynamicEntity updateValues = (DynamicEntity)context.InputParameters.Properties["Target"];
If( ([USER NOT AUTHORISED] ) && updateValues.Properties.Contains[“ATTRIBUTE_NAME”])
{
updateValues.Properties.Remove[“ATTRIBUTE_NAME”]);
}
During Retrieval, it is important to hide data from unauthorized users. This can be accomplished by using either a Pre-Retrieve or Post-Retrieve Plug-In. It is also necessary to provide a Pre-Update Plug-In to prevent unauthorized users from updating record fields that those users are not authorized to view or to update
2. Access via Views/Advanced Find - The underlying queries that these user interface elements use to retrieve data are sent to the platform via one of two types of messages, either by FetchXML requests sent through the Execute message or by RetrieveMultiple messages. Both types of messages must be filtered to ensure data security.
3. CRM Metadata web service – If the metadata service is used, it is not possible to hide the fact that information of a certain type is captured for a particular entity, and therefore other mechanisms should be used so as to hide the actual data captured against that attribute.
4. Export-to-Excel feature ensures that users can only export the data to which they have access. After enabling field-level security by using the plug-in approach, it is important to consider the Export-to-Excel capability to prevent data restricted through the UI from being accessed in this way.
Applying field-level security is more problematic with dynamic worksheets however, because the data is retrieved directly by the Excel worksheet at the client from the database by using the filtered views that the CRM product creates and exposes. There is no supported way to intercept or alter the data returned by the CRM provided Filtered Views. As a result, the best option available is to prevent direct access to the database Filtered Views altogether by the user from the client
5. To secure data that can be accessed by using reports, available options include:
• Disabling Reports access for roles that require field-level security.
• Disabling report creation for roles that require field-level security. Provide pre-defined custom reports for those users.
6. To secure direct access to Database Filtered Views, available options include:
• Denying user membership to the CRM Reporting Group.
7. Access via Outlook Synchronization and the Offline Client - If any of the data shared with Outlook (i.e. contacts, appointments, tasks) or the offline client needs to be limited at a field level for particular users, then those users must not be able to use the CRM Outlook add-in.
Comments
Post a Comment