Building HTML Applications for Microsoft Dynamics CRM – Security

It is my pleasure to present to you my first article about building HTML5 applications for Microsoft Dynamics CRM. The era of Silverlight is over, and many companies rewrite their existing products using HTML5 and JavaScript. I am going to provide you with some pieces of advice and best practices for building HTML5 applications for Microsoft Dynamics CRM, now known as Microsoft Dynamics 365.

Security issues with JavaScript

The first thing I want to point out is security issues with JavaScript. Using this language, anyone can see your code and mix it with custom scripts in the developer console in any browser. WebResources from Managed Solution can be easily changed and nothing remains protected. This is the main reason to reconsider using HTML and JavaScript. Unfortunately, until WebAssembly is released, there is no good alternative. Gathering libraries in one file with its subsequent minifying makes it harder to change or get business information. Nevertheless, it is not a cure.

Implementing a workaround using the basic CRM

Here, I want to propose to you a small workaround. As an example, let us use the basic CRM instance without custom handlers or ASP.NET endpoints – only WebResources and plugins. This should work for CRM on-premises and online. Upload your application to this CRM instance with service libraries. If you are just thinking about building an application, I will review some existing libraries to connect CRM services in my next article.

Now, let us try to create a new account entity with only one description field:

var record = new Entity("account", "");
 record.attributes["description"] = "run security logic";
 service.Create(record, callback, errorCallback);

Note: There are no classes in ECMA 5, but I will use this term to define functions used to create class instances.

In this case, “Entity” is a class for a CRM entity in Service Library and “service” is an object at least with a Create method. This method takes an Entity object, serializes it and sends it to the server for creation. Callback and errorCallback are functions, which service will call after the async server operation.

Name attributes are default in basic CRM, but API allows us to create records without required fields. In this case, we will get a kind of “broken” record in CRM every time the application runs this piece of code.

Creating a new plugin for an account entity

The second part is the plugins. Let us create a new plugin with the PreCreate step for an account entity with the following code:

protected override void PreCreate(IServiceProvider serviceProvider,
 IOrganizationService service, Entity target)
 {
 if (target.Contains("description")
 && target.GetAttributeValue("description")
 == "run security logic"
 && !target.Contains("name"))
 {
 throw new InvalidPluginExecutionException
 ("alert('everything is OK')");
 }
 }

This plugin step should handle the creation of “broken” account entities and throw exceptions. After running it, the service library should handle fault response from the server and call errorCallback with an error message as a parameter:

errorCallback = function (error) {
 eval(error);
 }

Here, you can execute errors from a plugin as JavaScript code in runtime and get an alert on the page letting you know that everything is OK. If the callback function was called, it means that something went wrong, and you can log all parameters using the console or another logging approach.

Alternative ideas to set up security

This is only one example of the idea that will help you store some security code in the CRM code-behind. Of course, you could create a new entity for this process and set up security in such a way that only the Admin would have rights to create new records. Additionally, you could use its fields as parameters for the plugin’s execution. Remember, a user can still see this error coming from server. Using this approach with Web API services is not a good idea because it is not stable and creates “broken” records.

Although this is not fit for all instances, for some key processes or licensing checks it is enough. Thus, you can start building your applications right now.
– May the CRM force be with you!

If you want to know how to set up security roles in Dynamics 365, check out this video: