Basic (but important) considerations about the Dynamics 365 security model

The Dynamics 365 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.

• Forms
• Dashboards
• Command bar buttons
• Business Process Flows
• The sitemap (or sitemaps, since 8.2, thanks to Business apps)
• Views (since 8.2, thanks to Business apps)
• Charts (since 8.2, thanks to Business apps)

Standing at the crossroads

 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)
    }
}

The post Basic (but important) considerations about the Dynamics 365 security model appeared first on CRM Deep Dive.