Erstellung von HTML-Anwendungen für Microsoft Dynamics CRM – Sicherheit

Dies ist mein erster Artikel über die Erstellung von HTML(5)-Anwendungen für Microsoft Dynamics CRM, heute bekannt als Microsoft Dynamics 365.. Die Silverlight-Ära ist nun vorbei und viele Unternehmen programmieren ihre vorhandenen Produkte mittels HTML und JavaScript neu. In diesem Artikel möchte ich Ihnen einige hilfreiche Tipps und die bewährten Verfahren für Erstellung von HTML-Anwendungen für Microsoft Dynamics CRM vorstellen.

Sicherheitsproblematik bei JavaScript

Als erstes möchte ich die Sicherheitsproblematik in JavaScript betonen. Jede*r kann Ihren Code einsehen und diesen zusammen mit einem benutzerdefinierten Skript in der Entwicklerkonsole in jedem Browser kombinieren. Web-Ressourcen aus der verwalteten Lösung können ganz einfach verändert werden und Ihre Daten sind nicht mehr geschützt. Das ist der Hauptgrund dafür, die Benutzung von HTML und JavaScript zu überdenken. Leider gibt es keine gute Alternative, solange Web-Assembly noch nicht veröffentlicht ist. Bibliotheken in einer Datei zu vereinen und anschließend zu verkleinern (Minifying) erschwert das Verändern von und das Zugreifen auf Unternehmensinformationen. Es ist jedoch keine finale Lösung.

Implementierung eines Workarounds mit einfachem CRM

Im Folgenden möchte ich Ihnen ein kleines Workaround vorstellen. Als Beispiel dient hier eine einfache CRM-Instanz ohne Custom-Handlers oder ASP.NET-Endpunkte – nur die Web-Ressourcen und Plug-ins. Diese sollte sowohl für CRM-On-Premises als auch für CRM-Online funktionieren. Laden Sie Ihre Anwendung in diese CRM-Instanz mit den Service-Bibliotheken hoch (wenn Sie bereits über die Entwicklung einer Anwendung nachdenken, werde ich in meinem nächsten Artikel einige vorhandene Bibliotheken vorstellen, um die CRM-Services zu verbinden).

Erstellen wir jetzt eine neue Account-Entität mit nur einem Beschreibungsfeld:

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

Hinweis: Es gibt keine Klassen in ECMA 5, ich werde aber hier diesen Begriff verwenden, um die für die Erstellung der Klassen-Instanzen genutzten Funktionen zu definieren.

In diesem Fall dient Entität als eine Klasse für die CRM-Entität in der Service-Bibliothek und Service ist ein Objekt zumindest mit einer Create-Methode. Diese Methode erfasst ein Entität-Objekt, serialisiert es und schickt es zur Erstellung an den Server. Callback und ErrorCallback sind die Funktionen, die nach der async-Server-Operation von dem Service aufgerufen werden.

In dem einfachen CRM ist der Attribut-Name voreingestellt, aber die API lässt uns Datensätze ohne erforderliche Felder erstellen. In diesem Fall erhalten wir jedes Mal, wenn die Anwendung diesen Teil des Codes ausführt, einen sogenannten „kaputten“ Datensatz im CRM.

Erstellen eines neuen Plugins für eine Account-Entität

Der zweite Teil sind die Plug-ins. Jetzt erstellen wir ein neues Plug-in mit dem PreCreate-Schritt für die Account-Entität mit folgendem 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 InvalidPlug-inExecutionException
 ("alert('everything is OK')");
 }
 }

Dieser Plug-in-Schritt muss die Erstellung der „kaputten“ Account-Entität handhaben und die Ausnahme ausschließen. Danach sollte die Service-Bibliothek die Fehlerreaktion vom Server handhaben und ErrorCallback mit der Fehlermeldung als einen Parameter aufrufen.

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

Hier können Sie den Fehler aus dem Plug-in als JavaScript-Code in der Laufzeit ausführen und werden auf der Seite benachrichtigt, dass alles in Ordnung ist. Wenn die Callback-Funktion aufgerufen wurde, bedeutet dies, dass etwas schiefgegangen ist und Sie können alle Parameter mit der Konsole oder anderem Erfassungsansatz loggen.

Alternative Ideen zur Schaffung von Sicherheit

Dies ist nur ein kleines Beispiel, um Ihnen zu helfen, zumindest einen Teil des Sicherheitscodes auf der CRM-Server-Seite zu speichern. Natürlich können Sie für diesen Prozess eine neue Entität erstellen und so die Sicherheit gewährleisten, indem nur der Admin neue Datensätze erstellen kann. Darüber hinaus können Sie deren Felder als Parameter für die Ausführung des Plug-ins nutzen. Denken Sie aber daran, dass Benutzer*innen immer noch einen Fehler vom Server angezeigt bekommen. Diesen Ansatz als Web-API-Service zu nutzen ist keine gute Idee, denn dieser ist instabil und erstellt „kaputte“ Datensätze.

Dennoch genügt dieser Ansatz für manche Schlüsselprozesse oder für die Lizenzüberprüfung. Also können Sie anfangen, Ihre Anwendungen zu erstellen. Möge die CRM-Macht mit Ihnen sein!

Wenn Sie wissen möchten, wie Sie Sicherheitsrollen in Dynamics 365 einstellen können, sehen Sie sich dieses Video an: