Basic but important considerations about the Dynamics 365 / CDS for Apps security model

The Dynamics 365 / Common Data Service for Apps security model

When it comes to data, security defines who has the right to do what on a record in the respective context of the user and the data.

Concerning the User Interface, security lets you adapt a number of items for users:
  • Forms 
  • Dashboards 
  • Command bar buttons 
  • Business Process Flows 
  • The sitemap (or sitemaps, since 8.2, thanks to App Modules
  • Views (since 8.2, thanks to App Modules
  • Charts (since 8.2, thanks to App Modules
On top of that, security also allows to define access to specific features, such as Excel Export, Printing, the use of the App for Outlook…

Standing at the crossroads 

Data security must be conceived as a meeting point between data and the user’s rights. The security model’s backbone, that enables those meetings, is the business units hierarchy.
I elaborate on the importance of the context of the user and the data in this article.


Customizing views and forms IS NOT securing data

Once configured, the security model applies regardless of the entry point of your users: through the Web interface, the Web Services, the SQL Filtered Views (On-Premise), the mobile application, the reports…

It is important to understand that forms that are associated with security roles do not restrict in any way access to CRM data. Contrary to field level security, forms are just an ergonomic presentation of your data (UI). The same goes for the columns you chose to display in a view, or the filter you decide to apply to it. Any user can bypass them by doing a simple Advanced Find.

Here’s an example of the impact of a JavaScript injected into a CRM form, that completely reveals and unlocks it:


On a similar note, resourceful users who have a read access to CRM data can access it through the Dynamics 365 Web Services, and thus be able to export them one way or another, even if the “Export to Excel” button is hidden to them.
Security can only be configured server-side, through the configuration of your users’ rights (business units hierarchy, users/teams configuration and their security role, entity relationships, field level security, positions…), and if necessary through custom logic that is executed with Plugins or Workflows. 

Example of hacks

By injecting this JavaScript code in a form, a user can display all hidden tabs, sections and fields, make editable all read-only fields, and remove any requirements for mandatory fields.

This injection can be done with the console of your browser, or by minifying this code and copying it as a bookmark URL (more examples here).

javascript: var form = $("iframe").filter(function () {
return $(this).css("visibility") == "visible"
})[0].contentWindow;
try {
form.Mscrm.InlineEditDataService.get_dataService().validateAndFireSaveEvents = function () {
return new Mscrm.SaveResponse(5, "")
}
} catch (e) { }
var attrs = form.Xrm.Page.data.entity.attributes.get();
for (var i in attrs) {
attrs[i].setRequiredLevel("none")
}
var contrs = form.Xrm.Page.ui.controls.get();
for (var i in contrs) {
try {
contrs[i].setVisible(true);
contrs[i].setDisabled(false);
contrs[i].clearNotification()
} catch (e) { }
}
var tabs = form.Xrm.Page.ui.tabs.get();
for (var i in tabs) {
tabs[i].setVisible(true);
tabs[i].setDisplayState("expanded");
var sects = tabs[i].sections.get();
for (var i in sects) {
sects[i].setVisible(true)
}
}

Another option is to install and use Sonoma Partners’ Dynamics CRM DevTools inthe Google Chrome extensions store:


Comments