Monthly Archives: December 2017

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.

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 Business apps)
  • Views (since 8.2, thanks to Business apps)
  • Charts (since 8.2, thanks to Business apps)
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 will elaborate more on importance of the context of the user and the data in an upcoming article.

CRM Crossing Paths Dynamics 365

 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:

CRM JavaScript Injection EN

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:
Sonoma Partners Dynamics CRM DevTools

Golden Rules to design a security model in Dynamics 365

I’m starting a new series of articles dedicated to security modeling in Dynamics 365 Customer Engagement.

The aim is to go beyond the basic principles that are already detailed in Customization and Configuration courses or on TechNet.
I will provide design tips, best practice and examples to simplify a CRM security model implementation and administration.

Dynamics 365 Security

Why is it crucial to address the security model early in a project?

  • The Dynamics 365 Customer Engagement security model is powerful and flexible: it offers many options that can be combined.
  • It must be addressed right from the start of your project, because chances are it will impact your data model and business rules.
  • You must always have in mind your security model, in particular when you design business processes or complex data models (e.g. business processes encompassing several entities, or entities with child records…)

Security model design Golden Rules

  • Have the future in mind: think about the administration effort when you will have to configure hundreds of users.
  • Keep it simple: at some point, new people will have to understand it and make it evolve.
  • Don’t sweep things under the carpet: it might be tempting to not address a potential security issue, but it’s best to spend time on it while you are designing your model rather than wait for users to notice it in production.
  • Negotiate: opinions can change on how strict or complex the security model should be!
  • Share: educate your customer on how the standard security model works and what different options it offers, it will then be easier to try to fit in.
  • Differentiate: are we talking about filtering what we see, or restricting access to data? Sometimes a filtered view is just what you need.
  • Scalability and performance: your model might work well for a few users, business units and records. How would it scale for hundreds of thousands / millions?

The different security model options and how you should address them

Dynamics 365 Security Options_EN