CRM Difference between Secure & Unsecure Configuration in Plugin Registration tool

Dear all,

Read original text  from the URL

Secure Configuration of Plugin Registration tool in CRM	Unsecure Configuration of Plugin Registration tool in CRM
The Secure Configuration information could be read only by CRM Administrators.(Eg: Restricted data from normal user could be supplied here)	Unsecure configuration information could be read by any user in CRM. Remember its public information (Eg: Parameter strings to be used in plugin could be supplied here)
Imagine that you include a plugin,plugin steps and activate them in asolution. Later solution was exportedas Managed Solution to anotherenvironment. In this scenario, thesupplied Secure configuration  information would NOTbe available in the new environment. The simple  reason behind this is to provide more security to the contents of Secure Configuration.	Imagine that you include a plugin, plugin steps and activate them in a solution. Later solution was exported as Managed Solution to another environment. In this scenario, the supplied Unsecure configuration values would be available in the new environment.

One of the benefits to the plug-in architecture of CRM 4.0 is the ability to store plug-ins in the CRM database so they may be used by multiple CRM servers. This introduces a slight complication regarding the storage of configuration information. Because the plug-in assembly doesn’t reside on the disk the normal method of using a .config file located with the assembly no longer works.

Luckily, the plug-in architecture solves this issue by allowing the developer to supply configuration information for each step executed by the plug-in.

Plug-in Configuration Architecture

As noted in the CRM SDK article, Writing the Plug-in Constructor, when creating your plug-in, you may define a constructor that passes two parameters to your plug-in: unsecure configuration and secure configuration:

   1: public class SamplePlugin : IPlugin

   2: {

   3:   public SamplePlugin(string unsecureConfig, string secureConfig)

   4:   {

   5:   }

   6: }

Both parameters are strings and may contain any configuration data, in any format, that you wish. For the purposes of this discussion, we will only be concerned with the unsecure configuration parameter.

Creating a Configuration Structure

Since most of us are familiar with the XML configuration provided by the standard Properties.Settings structure, I thought it would be a great idea to retain as much of that experience as possible so we can move code from a stand-alone test application to a plug-in with little difficulty.

Using an XML fragment that closely resembles the Settings section found in the .config file of a .Net assembly, we can create a similarly functional system for storing configuration data. Consider the following XML:

   1:

   2:     "RetryCount">

   3:         <value>5</value>

   4:    

   5:     "TaskPrefix">

   6:         <value>This task was created on {0}.</value>

   7:    

   8:     "FirstRun">

   9:         <value>false</value>

  10:    

  11:

As you can see, we have three settings which contain values that we would normally find in our .config file and which are used to configure our assembly. Using the Plug-in Registration Tool, we can add this information to the Unsecure Configuration field when registering a new step, as show by the figure below:

Plug-in Configuration Class

I created a simple class to extract values from an XML document for simple data types such as Guids, strings, Booleans, and integers, given the structure we discussed above:

   1: class PluginConfiguration

   2: {

   3:     private static string GetValueNode(XmlDocument doc, string key)

   4:     {

   5:         XmlNode node = doc.SelectSingleNode(String.Format("Settings/setting[@name='{0}']", key));

   6: 

   7:         if (node != null)

   8:         {

   9:             return node.SelectSingleNode("value").InnerText;

  10:         }

  11:         return string.Empty;

  12:     }

  13: 

  14:     public static Guid GetConfigDataGuid(XmlDocument doc, string label)

  15:     {

  16:         string tempString = GetValueNode(doc, label);

  17: 

  18:         if (tempString != string.Empty)

  19:         {

  20:             return new Guid(tempString);

  21:         }

  22:         return Guid.Empty;

  23:     }

  24: 

  25:     public static bool GetConfigDataBool(XmlDocument doc, string label)

  26:     {

  27:         bool retVar;

  28: 

  29:         if (bool.TryParse(GetValueNode(doc, label), out retVar))

  30:         {

  31:             return retVar;

  32:         }

  33:         else

  34:         {

  35:             return false;

  36:         }

  37:     }

  38: 

  39:     public static int GetConfigDataInt(XmlDocument doc, string label)

  40:     {

  41:         int retVar;

  42: 

  43:         if (int.TryParse(GetValueNode(doc, label), out retVar))

  44:         {

  45:             return retVar;

  46:         }

  47:         else

  48:         {

  49:             return -1;

  50:         }

  51:     }

  52: 

  53:     public static string GetConfigDataString(XmlDocument doc, string label)

  54:     {

  55:         return GetValueNode(doc, label);

  56:     }

  57: }

Putting PluginConfiguration to Work

Once we have our PluginConfiguration class added to our project, we need to modify the plug-in constructor to extract the values from our configuration string:

   1: public SamplePlugin(string unsecureConfig, string secureConfig)

   2: {

   3:     XmlDocument doc = new XmlDocument();

   4:     doc.LoadXml(unsecureConfig);

   5: 

   6:     string TaskPrefix = PluginConfiguration.GetConfigDataString(doc, "TaskPrefix");

   7:     bool FirstRun = PluginConfiguration.GetConfigDataBool(doc, "FirstRun");

   8:     int RetryCount = PluginConfiguration.GetConfigDataInt(doc, "RetryCount");

   9: }

There is no automatic determination of data types so you will need to know which method to use to extract a specific value from the configuration data.

have a glance below for plugin code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.Xrm.Sdk;
using System.Xml;

namespace ReadPluginConfgInPlugins
{
public class PluginConfg : IPlugin
{
private readonly string _unsecureString;
private readonly string _secureString;

public PluginConfg(string unsecureString, string secureString)
{
if (String.IsNullOrWhiteSpace(unsecureString) || String.IsNullOrWhiteSpace(secureString))
{
try
{
XmlDocument doc = new XmlDocument();
doc.LoadXml(unsecureString);
Guid DefaultQueueGuid = PluginConfiguration.GetConfigDataGuid(doc, “Contact Guid”);
string ContactFullName = PluginConfiguration.GetConfigDataString(doc, “Full Name”);
int MobileNumber = PluginConfiguration.GetConfigDataInt(doc, “Mobile Number”);
bool Gender = PluginConfiguration.GetConfigDataBool(doc, “Gender 0 refer to Male”);
}
catch (Exception ex)
{
throw new Exception(“SoapException” + ex.Message + “########” + ex.StackTrace + “$$$$Inner Exception” + ex.InnerException);
}
}
}

public void Execute(IServiceProvider serviceProvider)
{
//Extract the tracing service for use in debugging sandboxed plug-ins.
ITracingService tracingService =
(ITracingService)serviceProvider.GetService(typeof(ITracingService));

// Obtain the execution context from the service provider.
IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));

// For this sample, execute the plug-in code only while the client is online.
tracingService.Trace(“AdvancedPlugin: Verifying the client is not offline.”);
if (context.IsExecutingOffline || context.IsOfflinePlayback)
return;

// The InputParameters collection contains all the data passed
// in the message request.
if (context.InputParameters.Contains(“Target”) &&
context.InputParameters["Target"] is Entity)
{
Entity entity = (Entity)context.InputParameters["Target"];

}

}
}

}

For this approach also have a Pros and Cons.

PROS:

• The step configuration is solution-aware so it will be automatically transported with the plugin step.

CONS:

• You need to use the plugin registration tool or another application to update the step configuration.
• The configuration is step-specific so you have to provide it and/or update it for every step even if the value is the same for all the steps (the configuration is on each step instead of the assembly or plugin type).
• the configuration is just an attribute of the plugin step so you cannot control privileges on the configuration independently from privileges on plugin step entity.

*. Use the plugin step “Secure Configuration”
This is similar to the step Configuration except that the configuration data is stored in a separate entity which can be secured.
PROS:

• The configuration data can be secured as any other entity using the CRM security model. This is useful when the configuration contains sensitive information such as passwords.

CONS:

• Secure configuration is not solution aware so you will need to configure it for each environment.
• You need to use the plugin registration tool or another application to update the step configuration.
• The configuration is step-specific so you have to provide it and/or update it for every step even if the value is the same for all the steps (the configuration is on each step instead of the assembly or plugin type).

*. Use a Web Resource
You can store configuration information in web resources, for example you might have some XML configuration stored in a web resource and have your plugin read the web resource each time it executes.

PROS:

• Web resources are solution aware and the GUID is preserved across environments so you can hardcode the web resource GUID in your plugin code. You can transport the web resource and the plugin in the same solution.
• Can be easily updated using the CRM UI.

CONS:

• You cannot secure the configuration since it depends on the web resource access privileges and most users will need at least read access to web resources.