Authenticating dynamics CRM plugin to access Web API 2 methods

0
votes

I have written a plugin in dynamics CRM. This plugin accesses a few Web API 2 methods that are deployed in Azure cloud (via HTTPS). The plug-in is triggered when a contact data in the CRM changes. Many CRM account holders will update the contact data.

I am going to hard code a 'secret key' (a one time generated Guid) in the plug-in and send this key every time I access the web api methods. I'll validate this guid in the web api methods to prevent un-authorized access.

I do not like to store the secret key (guid) in the source code.

Questions

  1. What are my alternatives if do not want to 'hard code' the secret key?
  2. What are the security flaws in this approach?

Note

In general, all my Web APIs are authenticated by a custom authentication web api filter, but the Web APIs that are accessed from the plugin are not part of the custom authentication.

CRM version is 2013

2
dynamics-crmrestful-authentication

2 Answers

2
votes

As the previous answers states, the first option is to store your information in a configuration custom entity that you can retrieve from your plugin. Those records are going to be protected by the CRM security model, so if your plugin is running in the calling user context you will need to make sure that the users have privileges to read that information (not really a good idea) or change the plugin to be executed under an admin user context.

Another option is to use Secure/Unsecure Configuration: enter image description here Those are two (string) parameters that you can configure within the step and you will be able to read them from the plugin. I would say that the secure configuration fits your requirement but give it a look. You can also easily find how to implement it (example).

The third and last option that I can think of, is to create an XML WebResource and read it from the plugin. Again, you will need to make sure that the user context under the plugin is running has access to it.

1
votes

I don't think this approach will ever be secure.

It's possible to extract the plugin assembly from CRM. Someone could then disassemble the assembly and find the Guid. Effectively your password is stored in plain text.

At the very least you could store the user name/password/secret key in a CRM record. The CRM record can then be protected with CRM security.

You are probably better off implementing the authentication 'normally'.